You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Alexey Kudinov <le...@gmail.com> on 2013/02/02 23:06:33 UTC
errors deploying a cached referenced site
Hi,
I followed the procedure of creation of local referenced site(by indexing
some rdfs and deploying to the running instance of stanbol).
My launcher is custom, entityhub + enhancer, similar to what is described
in wiki.
I put the index zip into proper location, and deploy the bundle without
errors.
I'm using latest source code from trunk.
I'm getting the following errors after deployment:
02.02.2013 23:27:45.932 *ERROR* [Thread-43]
org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl Exception
while activating Index 'default:<..sitename..>'!
java.lang.IllegalArgumentException: The parsed File
'<..root..>\stanbol\indexes\default\<..sitename..>-2013.02.02' MUST
represent a Directory!
at
org.apache.stanbol.commons.solr.SolrServerAdapter$SolrCoreProperties.setCore
Dir(SolrServerAdapter.java:856)
at
org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.activateC
ore(ManagedSolrServerImpl.java:839)
at
org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.updateCor
e(ManagedSolrServerImpl.java:788)
at
org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl$IndexUpda
teDaemon.run(ManagedSolrServerImpl.java:1163)
indeed there is no such directory there. Recreating it manually doesn't
help.
And then this one:
02.02.2013 23:29:14.072 *WARN* [1612375055@qtp-115025036-6]
org.apache.felix.http.jetty /entityhub/site/<..sitename..>/find
(java.lang.IllegalStateException: Unable to initialize the Cache with Yard
<..sitename..>Index! This is usually caused by Errors while reading the
Cache Configuration from the Yard.) java.lang.IllegalStateException: Unable
to initialize the Cache with Yard <..sitename..>Index! This is usually
caused by Errors while reading the Cache Configuration from the Yard.
at
org.apache.stanbol.entityhub.core.site.CacheImpl.getCacheYard(CacheImpl.java
:214)
at
org.apache.stanbol.entityhub.core.site.CacheImpl.findRepresentation(CacheImp
l.java:331)
at
org.apache.stanbol.entityhub.core.impl.ReferencedSiteImpl.findEntities(Refer
encedSiteImpl.java:289)
at
org.apache.stanbol.entityhub.jersey.resource.ReferencedSiteRootResource.exec
uteLDPathQuery(ReferencedSiteRootResource.java:673)
at
org.apache.stanbol.entityhub.jersey.resource.ReferencedSiteRootResource.exec
uteQuery(ReferencedSiteRootResource.java:615)
at
org.apache.stanbol.entityhub.jersey.resource.ReferencedSiteRootResource.find
Entity(ReferencedSiteRootResource.java:559)
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
com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInv
okerFactory.java:60)
at
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispa
tchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvi
der.java:205)
at
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatche
r.dispatch(ResourceJavaMethodDispatcher.java:75)
at
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.ja
va:302)
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathR
ule.java:147)
at
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassR
ule.java:108)
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathR
ule.java:147)
at
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootReso
urceClassesRule.java:84)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(Web
ApplicationImpl.java:1480)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(Web
ApplicationImpl.java:1411)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebA
pplicationImpl.java:1360)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebA
pplicationImpl.java:1350)
at
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:
416)
at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContain
er.java:538)
at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContain
er.java:716)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletH
andler.java:96)
at
org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHan
dler.java:79)
at
org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletP
ipeline.java:42)
at
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(
InvocationFilterChain.java:49)
at
org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFi
lterChain.java:33)
at
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandl
er.java:78)
at
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(
InvocationFilterChain.java:47)
at
org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFi
lterChain.java:33)
at
org.apache.stanbol.commons.httpqueryheaders.impl.QueryHeadersFilter.doFilter
(QueryHeadersFilter.java:75)
at
org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHan
dler.java:88)
at
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandl
er.java:76)
at
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(
InvocationFilterChain.java:47)
at
org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFi
lterChain.java:33)
at
org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterP
ipeline.java:48)
at
org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.
java:39)
at
org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServ
let.java:67)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:
943)
at
org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582
)
Caused by: org.apache.stanbol.entityhub.servicesapi.yard.YardException: The
SolrIndex '<..sitename..>' for SolrYard '<..sitename..> Index' is currently
not active!
at
org.apache.stanbol.entityhub.yard.solr.impl.SolrYard.getServer(SolrYard.java
:546)
at
org.apache.stanbol.entityhub.yard.solr.impl.SolrYard.getRepresentation(SolrY
ard.java:901)
at
org.apache.stanbol.entityhub.core.site.CacheUtils.loadBaseMappings(CacheUtil
s.java:54)
at
org.apache.stanbol.entityhub.core.site.CacheImpl.initWithCacheYard(CacheImpl
.java:114)
at
org.apache.stanbol.entityhub.core.site.CacheImpl.getCacheYard(CacheImpl.java
:210)
... 55 more
Thanks,
Alexey
Re: errors deploying a cached referenced site
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi Alexey
the attachment was removed by the list. Please link the log or
alternatively try to send it directly to me.
best
Rupert
On Sun, Feb 3, 2013 at 8:00 PM, Alexey Kudinov <le...@gmail.com> wrote:
> Hi Rupert,
> Please find the log attached.
>
> -----Original Message-----
> From: Rupert Westenthaler [mailto:rupert.westenthaler@gmail.com]
> Sent: Sunday, February 03, 2013 11:37 AM
> To: dev@stanbol.apache.org
> Subject: Re: errors deploying a cached referenced site
>
> Hi
>
>
> On Sun, Feb 3, 2013 at 9:48 AM, Alexey Kudinov <le...@gmail.com> wrote:
>> I haven't changed any file name prior installation. I followed exactly
>> the tutorial on site. i gave a meaningful name to the site in
>> configuration file before indexing and that's it. somehow the directory wasn't created.
>>
>
> Ok, but than I have no clue why the directory is not created. Can you please start the Stanbol Server with log level DEBUG (-l DEBUG), reproduce this error and provide the resulting log file.
>
> best
> Rupert
>
>> Regards,
>> alexey
>> On Feb 3, 2013 9:06 AM, "Rupert Westenthaler"
>> <ru...@gmail.com>
>> wrote:
>>
>>> Hi Alexey
>>>
>>> On Sat, Feb 2, 2013 at 11:06 PM, Alexey Kudinov
>>> <le...@gmail.com>
>>> wrote:
>>> > I'm getting the following errors after deployment:
>>> >
>>> >
>>> >
>>> > 02.02.2013 23:27:45.932 *ERROR* [Thread-43]
>>> > org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl
>>> Exception
>>> > while activating Index 'default:<..sitename..>'!
>>> > java.lang.IllegalArgumentException: The parsed File
>>> > '<..root..>\stanbol\indexes\default\<..sitename..>-2013.02.02' MUST
>>> > represent a Directory!
>>> >
>>> > at
>>> >
>>> org.apache.stanbol.commons.solr.SolrServerAdapter$SolrCoreProperties.
>>> setCore
>>> > Dir(SolrServerAdapter.java:856)
>>> >
>>> > at
>>> >
>>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.ac
>>> tivateC
>>> > ore(ManagedSolrServerImpl.java:839)
>>> >
>>> > at
>>> >
>>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.up
>>> dateCor
>>> > e(ManagedSolrServerImpl.java:788)
>>> >
>>> > at
>>> >
>>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl$In
>>> dexUpda
>>> > teDaemon.run(ManagedSolrServerImpl.java:1163)
>>>
>>> The stacktrace suggest that the copying of the data form the Archive
>>> to the target directory was completed successful (because this part
>>> of the code is done before the location that throws the excaption).
>>> But than the check if the target directory exists fails. A detailed
>>> look at the code revealed that this can only happen if not a single
>>> file of the {sitename}.solrindex.zip file was copied (because
>>> directories are created lazily if actual resources are copied).
>>>
>>> Because of that I assume that you have renamed the
>>> "{sitename}.solrindex.zip" so that the {sitename} in the filename
>>> does no longer match the root directory within the archive. However
>>> this is required so that the initialization process can determine the
>>> relative path for copying the files (see specification in the section
>>> "Managing Solr Indexes" [1] of the commons-solr documentation).
>>>
>>> Users that want to rename a "{sitename}.solrindex.zip" file need
>>> therefore to extract the archive, change the name of the root
>>> directory and than re-comress the data.
>>>
>>> If this is indeed the case than the thrown exception is not very
>>> helpful and I will need to improve error handling to indicate the
>>> actual cause of the Problem.
>>>
>>> best
>>> Rupert
>>>
>>> [1]
>>> http://stanbol.apache.org/docs/trunk/utils/commons-solr#managing-solr
>>> -indexes
>>>
>>> --
>>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>>> | Bodenlehenstraße 11 ++43-699-11108907
>>> | A-5500 Bischofshofen
>>>
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: RE: errors deploying a cached referenced site
Posted by Rupert Westenthaler <ru...@gmail.com>.
ok than it might be related to '/' vs. '\'
<sitename>/ not found in resource <sitename>\{extra-path}
Can you please tell what platform you are using for indexing and
running the Stanbol Server. Mainly if you are using a Windows box or
Linux/Mac - as I am interested in why there are '/' and '\' in the
log.
best
Rupert
On Mon, Feb 4, 2013 at 6:39 PM, Alexey Kudinov <le...@gmail.com> wrote:
> very prompt response, thank you.
> yes, i obfuscated the name, but no special chars really, plain name in
> english.
>
> On Feb 4, 2013 7:35 PM, "Rupert Westenthaler"
> <ru...@gmail.com> wrote:
>>
>> Hi
>>
>> Thanks for providing the log file!
>>
>> My assumption was correct. The index data within the
>> {name}.solrindex.zip file gets ignored and because of that the
>> initialization fails. Here the according sections in the log
>>
>> 03.02.2013 20:50:44.626 *DEBUG* [Thread-40]
>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl >
>> start initializing SolrIndex {}<sitename>
>> 03.02.2013 20:50:44.627 *WARN* [Thread-40]
>> org.apache.stanbol.commons.solr.utils.ConfigUtils Context <sitename>/
>> not found in resource <sitename>\conf\admin-extra.html -> ignored!
>> [..a lot more ignored files..]
>>
>> resulting in the
>>
>> 03.02.2013 20:50:44.652 *ERROR* [Thread-40]
>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl
>> Exception while activating Index 'default:<sitename>'!
>> java.lang.IllegalArgumentException: The parsed File
>> '<root>\stanbol\indexes\default\<sitename>-2013.02.03' MUST represent
>> a Directory!
>>
>> So if - as you have confirmed - the {sitename} of the solrindex.zip
>> file is in fact the same as the {sitename} within the archive i am now
>> assuming that this has todo with the sitename you are using. As I
>> assume that you have modified the log to use '<sitename>' instead of
>> the real sitename there is not much I can do other than asking if you
>> use some non ASCII chars in your name. Because this would suggest that
>> this issue is related to character encoding issues with zip archive
>> entries.
>>
>> Can you please confirm this assumption. If true I would also expect
>> that choosing an ASCII only site name should solve this issue.
>>
>> best
>> Rupert
>>
>>
>> On Mon, Feb 4, 2013 at 6:23 PM, Alexey Kudinov <le...@gmail.com>
>> wrote:
>> > please find the debug log attached
>> > regards,
>> > alexey
>> >
>> > ---------- Forwarded message ----------
>> > From: "Alexey Kudinov" <le...@gmail.com>
>> > Date: Feb 3, 2013 8:56 PM
>> > Subject: RE: errors deploying a cached referenced site
>> > To: <de...@stanbol.apache.org>
>> >
>> > Hi Rupert,
>> > Please find the log attached.
>> >
>> > -----Original Message-----
>> > From: Rupert Westenthaler [mailto:rupert.westenthaler@gmail.com]
>> > Sent: Sunday, February 03, 2013 11:37 AM
>> > To: dev@stanbol.apache.org
>> > Subject: Re: errors deploying a cached referenced site
>> >
>> > Hi
>> >
>> >
>> > On Sun, Feb 3, 2013 at 9:48 AM, Alexey Kudinov <le...@gmail.com>
>> > wrote:
>> >> I haven't changed any file name prior installation. I followed exactly
>> >> the tutorial on site. i gave a meaningful name to the site in
>> >> configuration file before indexing and that's it. somehow the directory
>> >> wasn't created.
>> >>
>> >
>> > Ok, but than I have no clue why the directory is not created. Can you
>> > please
>> > start the Stanbol Server with log level DEBUG (-l DEBUG), reproduce this
>> > error and provide the resulting log file.
>> >
>> > best
>> > Rupert
>> >
>> >> Regards,
>> >> alexey
>> >> On Feb 3, 2013 9:06 AM, "Rupert Westenthaler"
>> >> <ru...@gmail.com>
>> >> wrote:
>> >>
>> >>> Hi Alexey
>> >>>
>> >>> On Sat, Feb 2, 2013 at 11:06 PM, Alexey Kudinov
>> >>> <le...@gmail.com>
>> >>> wrote:
>> >>> > I'm getting the following errors after deployment:
>> >>> >
>> >>> >
>> >>> >
>> >>> > 02.02.2013 23:27:45.932 *ERROR* [Thread-43]
>> >>> > org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl
>> >>> Exception
>> >>> > while activating Index 'default:<..sitename..>'!
>> >>> > java.lang.IllegalArgumentException: The parsed File
>> >>> > '<..root..>\stanbol\indexes\default\<..sitename..>-2013.02.02' MUST
>> >>> > represent a Directory!
>> >>> >
>> >>> > at
>> >>> >
>> >>> org.apache.stanbol.commons.solr.SolrServerAdapter$SolrCoreProperties.
>> >>> setCore
>> >>> > Dir(SolrServerAdapter.java:856)
>> >>> >
>> >>> > at
>> >>> >
>> >>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.ac
>> >>> tivateC
>> >>> > ore(ManagedSolrServerImpl.java:839)
>> >>> >
>> >>> > at
>> >>> >
>> >>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.up
>> >>> dateCor
>> >>> > e(ManagedSolrServerImpl.java:788)
>> >>> >
>> >>> > at
>> >>> >
>> >>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl$In
>> >>> dexUpda
>> >>> > teDaemon.run(ManagedSolrServerImpl.java:1163)
>> >>>
>> >>> The stacktrace suggest that the copying of the data form the Archive
>> >>> to the target directory was completed successful (because this part
>> >>> of the code is done before the location that throws the excaption).
>> >>> But than the check if the target directory exists fails. A detailed
>> >>> look at the code revealed that this can only happen if not a single
>> >>> file of the {sitename}.solrindex.zip file was copied (because
>> >>> directories are created lazily if actual resources are copied).
>> >>>
>> >>> Because of that I assume that you have renamed the
>> >>> "{sitename}.solrindex.zip" so that the {sitename} in the filename
>> >>> does no longer match the root directory within the archive. However
>> >>> this is required so that the initialization process can determine the
>> >>> relative path for copying the files (see specification in the section
>> >>> "Managing Solr Indexes" [1] of the commons-solr documentation).
>> >>>
>> >>> Users that want to rename a "{sitename}.solrindex.zip" file need
>> >>> therefore to extract the archive, change the name of the root
>> >>> directory and than re-comress the data.
>> >>>
>> >>> If this is indeed the case than the thrown exception is not very
>> >>> helpful and I will need to improve error handling to indicate the
>> >>> actual cause of the Problem.
>> >>>
>> >>> best
>> >>> Rupert
>> >>>
>> >>> [1]
>> >>> http://stanbol.apache.org/docs/trunk/utils/commons-solr#managing-solr
>> >>> -indexes
>> >>>
>> >>> --
>> >>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> >>> | Bodenlehenstraße 11 ++43-699-11108907
>> >>> | A-5500 Bischofshofen
>> >>>
>> >
>> >
>> >
>> > --
>> > | Rupert Westenthaler rupert.westenthaler@gmail.com
>> > | Bodenlehenstraße 11 ++43-699-11108907
>> > | A-5500 Bischofshofen
>>
>>
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: RE: errors deploying a cached referenced site
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi
Thanks for providing the log file!
My assumption was correct. The index data within the
{name}.solrindex.zip file gets ignored and because of that the
initialization fails. Here the according sections in the log
03.02.2013 20:50:44.626 *DEBUG* [Thread-40]
org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl >
start initializing SolrIndex {}<sitename>
03.02.2013 20:50:44.627 *WARN* [Thread-40]
org.apache.stanbol.commons.solr.utils.ConfigUtils Context <sitename>/
not found in resource <sitename>\conf\admin-extra.html -> ignored!
[..a lot more ignored files..]
resulting in the
03.02.2013 20:50:44.652 *ERROR* [Thread-40]
org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl
Exception while activating Index 'default:<sitename>'!
java.lang.IllegalArgumentException: The parsed File
'<root>\stanbol\indexes\default\<sitename>-2013.02.03' MUST represent
a Directory!
So if - as you have confirmed - the {sitename} of the solrindex.zip
file is in fact the same as the {sitename} within the archive i am now
assuming that this has todo with the sitename you are using. As I
assume that you have modified the log to use '<sitename>' instead of
the real sitename there is not much I can do other than asking if you
use some non ASCII chars in your name. Because this would suggest that
this issue is related to character encoding issues with zip archive
entries.
Can you please confirm this assumption. If true I would also expect
that choosing an ASCII only site name should solve this issue.
best
Rupert
On Mon, Feb 4, 2013 at 6:23 PM, Alexey Kudinov <le...@gmail.com> wrote:
> please find the debug log attached
> regards,
> alexey
>
> ---------- Forwarded message ----------
> From: "Alexey Kudinov" <le...@gmail.com>
> Date: Feb 3, 2013 8:56 PM
> Subject: RE: errors deploying a cached referenced site
> To: <de...@stanbol.apache.org>
>
> Hi Rupert,
> Please find the log attached.
>
> -----Original Message-----
> From: Rupert Westenthaler [mailto:rupert.westenthaler@gmail.com]
> Sent: Sunday, February 03, 2013 11:37 AM
> To: dev@stanbol.apache.org
> Subject: Re: errors deploying a cached referenced site
>
> Hi
>
>
> On Sun, Feb 3, 2013 at 9:48 AM, Alexey Kudinov <le...@gmail.com>
> wrote:
>> I haven't changed any file name prior installation. I followed exactly
>> the tutorial on site. i gave a meaningful name to the site in
>> configuration file before indexing and that's it. somehow the directory
>> wasn't created.
>>
>
> Ok, but than I have no clue why the directory is not created. Can you please
> start the Stanbol Server with log level DEBUG (-l DEBUG), reproduce this
> error and provide the resulting log file.
>
> best
> Rupert
>
>> Regards,
>> alexey
>> On Feb 3, 2013 9:06 AM, "Rupert Westenthaler"
>> <ru...@gmail.com>
>> wrote:
>>
>>> Hi Alexey
>>>
>>> On Sat, Feb 2, 2013 at 11:06 PM, Alexey Kudinov
>>> <le...@gmail.com>
>>> wrote:
>>> > I'm getting the following errors after deployment:
>>> >
>>> >
>>> >
>>> > 02.02.2013 23:27:45.932 *ERROR* [Thread-43]
>>> > org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl
>>> Exception
>>> > while activating Index 'default:<..sitename..>'!
>>> > java.lang.IllegalArgumentException: The parsed File
>>> > '<..root..>\stanbol\indexes\default\<..sitename..>-2013.02.02' MUST
>>> > represent a Directory!
>>> >
>>> > at
>>> >
>>> org.apache.stanbol.commons.solr.SolrServerAdapter$SolrCoreProperties.
>>> setCore
>>> > Dir(SolrServerAdapter.java:856)
>>> >
>>> > at
>>> >
>>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.ac
>>> tivateC
>>> > ore(ManagedSolrServerImpl.java:839)
>>> >
>>> > at
>>> >
>>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.up
>>> dateCor
>>> > e(ManagedSolrServerImpl.java:788)
>>> >
>>> > at
>>> >
>>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl$In
>>> dexUpda
>>> > teDaemon.run(ManagedSolrServerImpl.java:1163)
>>>
>>> The stacktrace suggest that the copying of the data form the Archive
>>> to the target directory was completed successful (because this part
>>> of the code is done before the location that throws the excaption).
>>> But than the check if the target directory exists fails. A detailed
>>> look at the code revealed that this can only happen if not a single
>>> file of the {sitename}.solrindex.zip file was copied (because
>>> directories are created lazily if actual resources are copied).
>>>
>>> Because of that I assume that you have renamed the
>>> "{sitename}.solrindex.zip" so that the {sitename} in the filename
>>> does no longer match the root directory within the archive. However
>>> this is required so that the initialization process can determine the
>>> relative path for copying the files (see specification in the section
>>> "Managing Solr Indexes" [1] of the commons-solr documentation).
>>>
>>> Users that want to rename a "{sitename}.solrindex.zip" file need
>>> therefore to extract the archive, change the name of the root
>>> directory and than re-comress the data.
>>>
>>> If this is indeed the case than the thrown exception is not very
>>> helpful and I will need to improve error handling to indicate the
>>> actual cause of the Problem.
>>>
>>> best
>>> Rupert
>>>
>>> [1]
>>> http://stanbol.apache.org/docs/trunk/utils/commons-solr#managing-solr
>>> -indexes
>>>
>>> --
>>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>>> | Bodenlehenstraße 11 ++43-699-11108907
>>> | A-5500 Bischofshofen
>>>
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
RE: errors deploying a cached referenced site
Posted by Alexey Kudinov <le...@gmail.com>.
Hi Rupert,
Please find the log attached.
-----Original Message-----
From: Rupert Westenthaler [mailto:rupert.westenthaler@gmail.com]
Sent: Sunday, February 03, 2013 11:37 AM
To: dev@stanbol.apache.org
Subject: Re: errors deploying a cached referenced site
Hi
On Sun, Feb 3, 2013 at 9:48 AM, Alexey Kudinov <le...@gmail.com> wrote:
> I haven't changed any file name prior installation. I followed exactly
> the tutorial on site. i gave a meaningful name to the site in
> configuration file before indexing and that's it. somehow the directory wasn't created.
>
Ok, but than I have no clue why the directory is not created. Can you please start the Stanbol Server with log level DEBUG (-l DEBUG), reproduce this error and provide the resulting log file.
best
Rupert
> Regards,
> alexey
> On Feb 3, 2013 9:06 AM, "Rupert Westenthaler"
> <ru...@gmail.com>
> wrote:
>
>> Hi Alexey
>>
>> On Sat, Feb 2, 2013 at 11:06 PM, Alexey Kudinov
>> <le...@gmail.com>
>> wrote:
>> > I'm getting the following errors after deployment:
>> >
>> >
>> >
>> > 02.02.2013 23:27:45.932 *ERROR* [Thread-43]
>> > org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl
>> Exception
>> > while activating Index 'default:<..sitename..>'!
>> > java.lang.IllegalArgumentException: The parsed File
>> > '<..root..>\stanbol\indexes\default\<..sitename..>-2013.02.02' MUST
>> > represent a Directory!
>> >
>> > at
>> >
>> org.apache.stanbol.commons.solr.SolrServerAdapter$SolrCoreProperties.
>> setCore
>> > Dir(SolrServerAdapter.java:856)
>> >
>> > at
>> >
>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.ac
>> tivateC
>> > ore(ManagedSolrServerImpl.java:839)
>> >
>> > at
>> >
>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.up
>> dateCor
>> > e(ManagedSolrServerImpl.java:788)
>> >
>> > at
>> >
>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl$In
>> dexUpda
>> > teDaemon.run(ManagedSolrServerImpl.java:1163)
>>
>> The stacktrace suggest that the copying of the data form the Archive
>> to the target directory was completed successful (because this part
>> of the code is done before the location that throws the excaption).
>> But than the check if the target directory exists fails. A detailed
>> look at the code revealed that this can only happen if not a single
>> file of the {sitename}.solrindex.zip file was copied (because
>> directories are created lazily if actual resources are copied).
>>
>> Because of that I assume that you have renamed the
>> "{sitename}.solrindex.zip" so that the {sitename} in the filename
>> does no longer match the root directory within the archive. However
>> this is required so that the initialization process can determine the
>> relative path for copying the files (see specification in the section
>> "Managing Solr Indexes" [1] of the commons-solr documentation).
>>
>> Users that want to rename a "{sitename}.solrindex.zip" file need
>> therefore to extract the archive, change the name of the root
>> directory and than re-comress the data.
>>
>> If this is indeed the case than the thrown exception is not very
>> helpful and I will need to improve error handling to indicate the
>> actual cause of the Problem.
>>
>> best
>> Rupert
>>
>> [1]
>> http://stanbol.apache.org/docs/trunk/utils/commons-solr#managing-solr
>> -indexes
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
>>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: errors deploying a cached referenced site
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi
On Sun, Feb 3, 2013 at 9:48 AM, Alexey Kudinov <le...@gmail.com> wrote:
> I haven't changed any file name prior installation. I followed exactly the
> tutorial on site. i gave a meaningful name to the site in configuration
> file before indexing and that's it. somehow the directory wasn't created.
>
Ok, but than I have no clue why the directory is not created. Can you
please start the Stanbol Server with log level DEBUG (-l DEBUG),
reproduce this error and provide the resulting log file.
best
Rupert
> Regards,
> alexey
> On Feb 3, 2013 9:06 AM, "Rupert Westenthaler" <ru...@gmail.com>
> wrote:
>
>> Hi Alexey
>>
>> On Sat, Feb 2, 2013 at 11:06 PM, Alexey Kudinov <le...@gmail.com>
>> wrote:
>> > I'm getting the following errors after deployment:
>> >
>> >
>> >
>> > 02.02.2013 23:27:45.932 *ERROR* [Thread-43]
>> > org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl
>> Exception
>> > while activating Index 'default:<..sitename..>'!
>> > java.lang.IllegalArgumentException: The parsed File
>> > '<..root..>\stanbol\indexes\default\<..sitename..>-2013.02.02' MUST
>> > represent a Directory!
>> >
>> > at
>> >
>> org.apache.stanbol.commons.solr.SolrServerAdapter$SolrCoreProperties.setCore
>> > Dir(SolrServerAdapter.java:856)
>> >
>> > at
>> >
>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.activateC
>> > ore(ManagedSolrServerImpl.java:839)
>> >
>> > at
>> >
>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.updateCor
>> > e(ManagedSolrServerImpl.java:788)
>> >
>> > at
>> >
>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl$IndexUpda
>> > teDaemon.run(ManagedSolrServerImpl.java:1163)
>>
>> The stacktrace suggest that the copying of the data form the Archive
>> to the target directory was completed successful (because this part of
>> the code is done before the location that throws the excaption). But
>> than the check if the target directory exists fails. A detailed look
>> at the code revealed that this can only happen if not a single file of
>> the {sitename}.solrindex.zip file was copied (because directories are
>> created lazily if actual resources are copied).
>>
>> Because of that I assume that you have renamed the
>> "{sitename}.solrindex.zip" so that the {sitename} in the filename does
>> no longer match the root directory within the archive. However this is
>> required so that the initialization process can determine the relative
>> path for copying the files (see specification in the section "Managing
>> Solr Indexes" [1] of the commons-solr documentation).
>>
>> Users that want to rename a "{sitename}.solrindex.zip" file need
>> therefore to extract the archive, change the name of the root
>> directory and than re-comress the data.
>>
>> If this is indeed the case than the thrown exception is not very
>> helpful and I will need to improve error handling to indicate the
>> actual cause of the Problem.
>>
>> best
>> Rupert
>>
>> [1]
>> http://stanbol.apache.org/docs/trunk/utils/commons-solr#managing-solr-indexes
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
>>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: errors deploying a cached referenced site
Posted by Alexey Kudinov <le...@gmail.com>.
I haven't changed any file name prior installation. I followed exactly the
tutorial on site. i gave a meaningful name to the site in configuration
file before indexing and that's it. somehow the directory wasn't created.
Regards,
alexey
On Feb 3, 2013 9:06 AM, "Rupert Westenthaler" <ru...@gmail.com>
wrote:
> Hi Alexey
>
> On Sat, Feb 2, 2013 at 11:06 PM, Alexey Kudinov <le...@gmail.com>
> wrote:
> > I'm getting the following errors after deployment:
> >
> >
> >
> > 02.02.2013 23:27:45.932 *ERROR* [Thread-43]
> > org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl
> Exception
> > while activating Index 'default:<..sitename..>'!
> > java.lang.IllegalArgumentException: The parsed File
> > '<..root..>\stanbol\indexes\default\<..sitename..>-2013.02.02' MUST
> > represent a Directory!
> >
> > at
> >
> org.apache.stanbol.commons.solr.SolrServerAdapter$SolrCoreProperties.setCore
> > Dir(SolrServerAdapter.java:856)
> >
> > at
> >
> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.activateC
> > ore(ManagedSolrServerImpl.java:839)
> >
> > at
> >
> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.updateCor
> > e(ManagedSolrServerImpl.java:788)
> >
> > at
> >
> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl$IndexUpda
> > teDaemon.run(ManagedSolrServerImpl.java:1163)
>
> The stacktrace suggest that the copying of the data form the Archive
> to the target directory was completed successful (because this part of
> the code is done before the location that throws the excaption). But
> than the check if the target directory exists fails. A detailed look
> at the code revealed that this can only happen if not a single file of
> the {sitename}.solrindex.zip file was copied (because directories are
> created lazily if actual resources are copied).
>
> Because of that I assume that you have renamed the
> "{sitename}.solrindex.zip" so that the {sitename} in the filename does
> no longer match the root directory within the archive. However this is
> required so that the initialization process can determine the relative
> path for copying the files (see specification in the section "Managing
> Solr Indexes" [1] of the commons-solr documentation).
>
> Users that want to rename a "{sitename}.solrindex.zip" file need
> therefore to extract the archive, change the name of the root
> directory and than re-comress the data.
>
> If this is indeed the case than the thrown exception is not very
> helpful and I will need to improve error handling to indicate the
> actual cause of the Problem.
>
> best
> Rupert
>
> [1]
> http://stanbol.apache.org/docs/trunk/utils/commons-solr#managing-solr-indexes
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
>
Re: errors deploying a cached referenced site
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi Alexey
On Sat, Feb 2, 2013 at 11:06 PM, Alexey Kudinov <le...@gmail.com> wrote:
> I'm getting the following errors after deployment:
>
>
>
> 02.02.2013 23:27:45.932 *ERROR* [Thread-43]
> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl Exception
> while activating Index 'default:<..sitename..>'!
> java.lang.IllegalArgumentException: The parsed File
> '<..root..>\stanbol\indexes\default\<..sitename..>-2013.02.02' MUST
> represent a Directory!
>
> at
> org.apache.stanbol.commons.solr.SolrServerAdapter$SolrCoreProperties.setCore
> Dir(SolrServerAdapter.java:856)
>
> at
> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.activateC
> ore(ManagedSolrServerImpl.java:839)
>
> at
> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.updateCor
> e(ManagedSolrServerImpl.java:788)
>
> at
> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl$IndexUpda
> teDaemon.run(ManagedSolrServerImpl.java:1163)
The stacktrace suggest that the copying of the data form the Archive
to the target directory was completed successful (because this part of
the code is done before the location that throws the excaption). But
than the check if the target directory exists fails. A detailed look
at the code revealed that this can only happen if not a single file of
the {sitename}.solrindex.zip file was copied (because directories are
created lazily if actual resources are copied).
Because of that I assume that you have renamed the
"{sitename}.solrindex.zip" so that the {sitename} in the filename does
no longer match the root directory within the archive. However this is
required so that the initialization process can determine the relative
path for copying the files (see specification in the section "Managing
Solr Indexes" [1] of the commons-solr documentation).
Users that want to rename a "{sitename}.solrindex.zip" file need
therefore to extract the archive, change the name of the root
directory and than re-comress the data.
If this is indeed the case than the thrown exception is not very
helpful and I will need to improve error handling to indicate the
actual cause of the Problem.
best
Rupert
[1] http://stanbol.apache.org/docs/trunk/utils/commons-solr#managing-solr-indexes
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen