You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Solr User <so...@gmail.com> on 2016/11/07 22:47:13 UTC
ClassNotFoundException with Custom ZkACLProvider
This is mostly just an FYI regarding future work on issues like SOLR-8792.
I wanted admin update but world read on ZK since I do not have anything
sensitive from a read perspective in the Solr data and did not want to
force all SolrCloud clients to implement authentication just for read. So,
I extended DefaultZkACLProvider and implemented a replacement for
VMParamsAllAndReadonlyDigestZkACLProvider.
My custom code is loaded from the sharedLib in solr.xml. However, there is
a temporary ZK lookup to read solr.xml (and chroot) which is obviously done
before loading sharedLib. Therefore, I am faced with a
ClassNotFoundException. This has no negative effect on the ACL
functionality....just the annoying stack trace in the logs. I do not want
to package this custom code with the Solr code and do not want to package
this along with Solr dependencies in the Jetty lib/ext.
So, I am planning to live with the stack trace and just wanted to share
this for any future work on the dynamic solr.xml and chroot lookups or in
case I am missing some work-around.
Thanks!
Re: ClassNotFoundException with Custom ZkACLProvider
Posted by Mark Miller <ma...@gmail.com>.
Could you file a JIRA issue so that this report does not get lost?
- Mark
On Tue, Nov 15, 2016 at 10:49 AM Solr User <so...@gmail.com> wrote:
> For those interested, I ended up bundling the customized ACL provider with
> the solr.war. I could not stomach looking at the stack trace in the logs.
>
> On Mon, Nov 7, 2016 at 4:47 PM, Solr User <so...@gmail.com> wrote:
>
> > This is mostly just an FYI regarding future work on issues like
> SOLR-8792.
> >
> > I wanted admin update but world read on ZK since I do not have anything
> > sensitive from a read perspective in the Solr data and did not want to
> > force all SolrCloud clients to implement authentication just for read.
> So,
> > I extended DefaultZkACLProvider and implemented a replacement for
> > VMParamsAllAndReadonlyDigestZkACLProvider.
> >
> > My custom code is loaded from the sharedLib in solr.xml. However, there
> > is a temporary ZK lookup to read solr.xml (and chroot) which is obviously
> > done before loading sharedLib. Therefore, I am faced with a
> > ClassNotFoundException. This has no negative effect on the ACL
> > functionality....just the annoying stack trace in the logs. I do not
> want
> > to package this custom code with the Solr code and do not want to package
> > this along with Solr dependencies in the Jetty lib/ext.
> >
> > So, I am planning to live with the stack trace and just wanted to share
> > this for any future work on the dynamic solr.xml and chroot lookups or in
> > case I am missing some work-around.
> >
> > Thanks!
> >
> >
>
--
- Mark
about.me/markrmiller
Re: ClassNotFoundException with Custom ZkACLProvider
Posted by Solr User <so...@gmail.com>.
For those interested, I ended up bundling the customized ACL provider with
the solr.war. I could not stomach looking at the stack trace in the logs.
On Mon, Nov 7, 2016 at 4:47 PM, Solr User <so...@gmail.com> wrote:
> This is mostly just an FYI regarding future work on issues like SOLR-8792.
>
> I wanted admin update but world read on ZK since I do not have anything
> sensitive from a read perspective in the Solr data and did not want to
> force all SolrCloud clients to implement authentication just for read. So,
> I extended DefaultZkACLProvider and implemented a replacement for
> VMParamsAllAndReadonlyDigestZkACLProvider.
>
> My custom code is loaded from the sharedLib in solr.xml. However, there
> is a temporary ZK lookup to read solr.xml (and chroot) which is obviously
> done before loading sharedLib. Therefore, I am faced with a
> ClassNotFoundException. This has no negative effect on the ACL
> functionality....just the annoying stack trace in the logs. I do not want
> to package this custom code with the Solr code and do not want to package
> this along with Solr dependencies in the Jetty lib/ext.
>
> So, I am planning to live with the stack trace and just wanted to share
> this for any future work on the dynamic solr.xml and chroot lookups or in
> case I am missing some work-around.
>
> Thanks!
>
>