Hi Simon,
I had the same issue with a customer, too (for a custom RewriteMethod). I used reflection to call the method :-)
I agree with you, the bug is the following:
getEnum() is protected so it is intended to be called *only* by subclasses (that’s the idea behind protected methods). They are also accessible by other classes from the same package, but that’s more a Java bug than a feature. The problem with MTQ is that RewriteMethod is a separate *class* and *not a subclass* of MTQ, so the method cannot be called (it can because of the "java bug" called from same package). So theoretically it has to be public otherwise you cannot call getEnum().
Another cleaner fix would be to add a protected final method to RewriteMethod that calls this method from MTQ. So anything subclassing RewriteMethod can get the enum from inside the RewriteMethod class which is the "correct" way to handle it. Delegating to MTQ is then "internal".
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.deeMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Simon Willnauer [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 15, 2012 2:13 PM
> To: Robert Muir
> Cc: [EMAIL PROTECTED]
> Subject: Re: why is MTQ#getEnum protected
>
> On Wed, Feb 15, 2012 at 11:55 AM, Robert Muir <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 15, 2012 at 5:18 AM, Simon Willnauer
> > <[EMAIL PROTECTED]> wrote:
> >> hey guys, I am working on different rewrite methods etc. and the fact
> >> that getEnum is protected drives me nuts. I always have to put stuff
> >> into the o.a.l.search package if I want to access this method and
> >> even further this only works if I am loaded by the same classloader
> >> so if somebody wants to write a super smart RewriteMethod and they
> >> are running in a tomcat etc. they could get in big trouble. Can we
> >> make this public?
> >
> > Wait: lets rephrase the question 'why should it be public?'
>
> well in my case it should be public because I simply wanna implement a rewrite
> method as well as a related consumer of the MTQ. Putting classes in a
> o.a.l.search package seems odd for such a essential method.
> >
> > whats the big trouble with tomcat? I've used tomcat with code that
> > uses package-private methods before, it works fine. Do you have a test
> > case where it fails?
>
> I confused something here, sorry. this only applies if you want to subclass a
> package private class, but the general problem is not tomcat. I should have
> phrased it differently. if you have two jars A
> (lucene-core.jar) and B (my-custom-code.jar) and B contains a Class that
> subclasses a package private class from A it works only as long as A and B are
> loaded by the same classloader. if not you get a ClassNotFound exception....
>
> > If so, that seems like a tomcat bug.
> >
> > I think this is pretty expert... whats wrong with package private
> > access for serious-expert stuff?
>
> I don't think experts need to put classes in o.a.l packages to get access to a
> feature
> > Sneaky bugs can happen in MTQ by making something visible/non-final:
> > stuff like LUCENE-3238... I think we should be careful.
>
> I agree but making this particular method public is hardly causing any
> sideeffects or do I miss something?
>
>
> >
> > --
> > lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
