You both convinced me this is the right functional approach -and that no
(mostly) technical trick alone would meet those (the last one was not
working btw, some class loading security errors, ugh...).
Note for self: Clear constraints are better than a 'free for all' feature
that will ultimately
It may be too late but just for the sake of argument, Hoss's idea about a
ResourceLoader triggered more thinking...(sorry, I'm not as fast as Hoss). I
also remembered that things were easier before solr-215 because the core
config were singletons. How could we get some sort of singletons back?
Henrib wrote:
It may be too late but just for the sake of argument, Hoss's idea about a
ResourceLoader triggered more thinking...(sorry, I'm not as fast as Hoss).
nonsense! of course its not too late. Its great to get feedback and new
ideas anytime - the goal is to make sure that we like
: The cleanest solution is to have a single place manage Aware/Inform. The
: cleanest place for this is in ResourceLoader (refactored Config superclass)
Mmm i wasn't assuming it would work that way ... in fact, i was pretty
sure it couldn't work that way for the reasons you outlined.
it
: nonsense! of course its not too late. Its great to get feedback and new ideas
: anytime - the goal is to make sure that we like where we end up and we feel
: confident we haven't missed something. A few loops in the middle are to be
: expected.
Agreed ... for what it's worth Henri: In my
...the only thing slightly non-standard about calling these methods
setters is that they aren't expected to jsut be POJO style setters ...
the expectation is that the class will do some work when they are called
-- hence my tell (or maybe notify or inform is a better verb)
suggestion.
I started implementing this suggestion and am running into one hitch.
The cleanest solution is to have a single place manage Aware/Inform.
The cleanest place for this is in ResourceLoader (refactored Config
superclass)
public Object newInstance(String cname, String... subpackages) {
...
Definitely a simpler more practical route - it avoids all previously
inelegant lately unorthodox pitfalls :-)
The only thing that this leaves behind is solr-399; I guess it's ok, we can
revive this after 1.3.
I've got a 414 + 350 + 409 working but I don't know where to upload it.
Should we
Henrib wrote:
Definitely a simpler more practical route - it avoids all previously
inelegant lately unorthodox pitfalls :-)
The only thing that this leaves behind is solr-399; I guess it's ok, we can
revive this after 1.3.
Yes, this leaves behind the 399 post core initialization callback.
Yes, I'm ok with it, please do.
ryantxu wrote:
...
If you feel ok with 414, I will commit it.
...
--
View this message in context:
http://www.nabble.com/Initializing---break-init%28%29-API-compatibility--tf4808463.html#a13839870
Sent from the Solr - Dev mailing list archive at
Hey guys, i'm *WAY* behind on my email, ironicly due to going mostly off
the grid while at a apachecon -- but the first thing i'm trying to do is
get caught up with what's going on here.
if i can sum up my understanding (and please correct me if i'm wrong, this
is based purely on email and
...Did i get that all right?
wow! you are good!
The one key point you did not mention is that the ThreadLocal approach
is proposed as a stop-gap measure until we have an API breaking release.
In the 2.0 release, the init() method signature will change and the
ThreadLocal hack will go
The bit of magic is in using some controlled Duck Typing to find the correct
method if it exists in the instance.
I'll try uploading the raw code for the Compatiblity package in case this
leaves you wondering.
Uggg. this is an impressive option! But it feels like a HUGE hammer
for a small
So, how do we proceed now ?
How do we reach closure on the topic ?
I just posted SOLR-414, I think this is our best 1.2 compatible
solution. We will need to document the deprecation path well.
Does this look ok?
Since this patch does not suggest new API changes (it rolls back
SOLR-215
On the premise that no API change would/will be allowed in the current
version, I've pursued experimentation and reached a solution.
Of course, if we were to change the API in 1.3, that makes what follows a
moot point.
So, let's assume we can only change the API in 1.4 after we deprecated in
1.3.
The Compatiblity package:
http://www.nabble.com/file/p13797408/Compatibility.java Compatibility.java
--
View this message in context:
http://www.nabble.com/Initializing---break-init%28%29-API-compatibility--tf4808463.html#a13797408
Sent from the Solr - Dev mailing list archive at Nabble.com.
I may have an alternative that would preserve the existing 1.2 'init' APIs
and still keep (hopefully all) the solr-399 features.
To instantiate a core, we need a schema and config; to instantiate a schema,
we need a config - and the core config schema config should be the same.
I'm
Instead of changing 'init' ( keeping the 1.2 version), we can either make
classes take a solrSystem as (first) constructor parameter (but I know this
is not the current nor preferred usage)
Are you saying 'if a constructor exists that takes a solrSystem, it will
use that - otherwise, just
For people not following:
http://www.nabble.com/SolrConfig.Initializable-tf4665036.html
In looking at how initialization throughout solr, I think the cleanest
and best approach to move forward is to break the existing init() method
for:
1. TokenFilterFactory.init( MapString,String args )
2.
19 matches
Mail list logo
