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]

Reply via email to