You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Simon Willnauer <si...@gmail.com> on 2013/04/23 13:50:09 UTC
[VOTE] Lucene Solr 4.3.0 RC3
Here is a new RC candidate...
http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
here is my +1
thanks for voting...
simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
+1
On Tue, Apr 23, 2013 at 5:20 PM, Simon Willnauer
<si...@gmail.com>wrote:
> Here is a new RC candidate...
>
>
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
>
> here is my +1
>
> thanks for voting...
>
> simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Regards,
Shalin Shekhar Mangar.
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Adrien Grand <jp...@gmail.com>.
On Tue, Apr 23, 2013 at 1:50 PM, Simon Willnauer
<si...@gmail.com> wrote:
> Here is a new RC candidate...
>
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
+1
--
Adrien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Andi Vajda <va...@osafoundation.org>.
+1 !
PyLucene 4.3 built from this RC rev builds and passes its tests.
Andi..
On Tue, 23 Apr 2013, Simon Willnauer wrote:
> Here is a new RC candidate...
>
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
>
> here is my +1
>
> thanks for voting...
>
> simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Steve Rowe <sa...@gmail.com>.
Hoss posting on SOLR-4729 reminded me that I'd like to get this bugfix into the next RC - I'll commit it to lucene_solr_4_3 now.
Simon, if you've already started an RC, that's fine, it's not super-critical that SOLR-4729 is included.
- Steve
On Apr 26, 2013, at 5:06 PM, Simon Willnauer <si...@gmail.com> wrote:
> Thanks guys,
>
> I will re-spin once I have a better inet connection
>
> simon
>
> On Fri, Apr 26, 2013 at 10:38 PM, Mark Miller <ma...@gmail.com> wrote:
>> Steve also seems to have committed the logging improvement. Simon, this should all be resolved.
>>
>> Thanks,
>>
>> - Mark
>>
>> On Apr 26, 2013, at 3:31 PM, Mark Miller <ma...@gmail.com> wrote:
>>
>>> I committed a fix.
>>>
>>> - Mark
>>>
>>> On Apr 26, 2013, at 3:07 PM, Mark Miller <ma...@gmail.com> wrote:
>>>
>>>> This is a nasty ugly ass bug with an annoying workaround. I'm committing a fix now.
>>>>
>>>> Hossman did bring it up to me a while ago, but I was too busy to comprehend it or look into it.
>>>>
>>>> - Mark
>>>>
>>>> On Apr 26, 2013, at 2:00 PM, Yonik Seeley <yo...@lucidworks.com> wrote:
>>>>
>>>>> On Wed, Apr 24, 2013 at 5:18 PM, Chris Hostetter
>>>>> <ho...@fucit.org> wrote:
>>>>>> FWIW: During my testing I did encounter one new bug: SOLR-4754, but since
>>>>>> it has a workarround (and i have no idea yet what the underlying problem
>>>>>> is to even try for a quick fix) I don't think it should block the release.
>>>>>
>>>>> Since it looks like there's going to be another respin, I've changed
>>>>> this issue to a blocker since we need to do *something* about it
>>>>> before 4.3 is announced.
>>>>> Comments in the issue.
>>>>>
>>>>> -Yonik
>>>>> http://lucidworks.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Simon Willnauer <si...@gmail.com>.
Thanks guys,
I will re-spin once I have a better inet connection
simon
On Fri, Apr 26, 2013 at 10:38 PM, Mark Miller <ma...@gmail.com> wrote:
> Steve also seems to have committed the logging improvement. Simon, this should all be resolved.
>
> Thanks,
>
> - Mark
>
> On Apr 26, 2013, at 3:31 PM, Mark Miller <ma...@gmail.com> wrote:
>
>> I committed a fix.
>>
>> - Mark
>>
>> On Apr 26, 2013, at 3:07 PM, Mark Miller <ma...@gmail.com> wrote:
>>
>>> This is a nasty ugly ass bug with an annoying workaround. I'm committing a fix now.
>>>
>>> Hossman did bring it up to me a while ago, but I was too busy to comprehend it or look into it.
>>>
>>> - Mark
>>>
>>> On Apr 26, 2013, at 2:00 PM, Yonik Seeley <yo...@lucidworks.com> wrote:
>>>
>>>> On Wed, Apr 24, 2013 at 5:18 PM, Chris Hostetter
>>>> <ho...@fucit.org> wrote:
>>>>> FWIW: During my testing I did encounter one new bug: SOLR-4754, but since
>>>>> it has a workarround (and i have no idea yet what the underlying problem
>>>>> is to even try for a quick fix) I don't think it should block the release.
>>>>
>>>> Since it looks like there's going to be another respin, I've changed
>>>> this issue to a blocker since we need to do *something* about it
>>>> before 4.3 is announced.
>>>> Comments in the issue.
>>>>
>>>> -Yonik
>>>> http://lucidworks.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Mark Miller <ma...@gmail.com>.
Steve also seems to have committed the logging improvement. Simon, this should all be resolved.
Thanks,
- Mark
On Apr 26, 2013, at 3:31 PM, Mark Miller <ma...@gmail.com> wrote:
> I committed a fix.
>
> - Mark
>
> On Apr 26, 2013, at 3:07 PM, Mark Miller <ma...@gmail.com> wrote:
>
>> This is a nasty ugly ass bug with an annoying workaround. I'm committing a fix now.
>>
>> Hossman did bring it up to me a while ago, but I was too busy to comprehend it or look into it.
>>
>> - Mark
>>
>> On Apr 26, 2013, at 2:00 PM, Yonik Seeley <yo...@lucidworks.com> wrote:
>>
>>> On Wed, Apr 24, 2013 at 5:18 PM, Chris Hostetter
>>> <ho...@fucit.org> wrote:
>>>> FWIW: During my testing I did encounter one new bug: SOLR-4754, but since
>>>> it has a workarround (and i have no idea yet what the underlying problem
>>>> is to even try for a quick fix) I don't think it should block the release.
>>>
>>> Since it looks like there's going to be another respin, I've changed
>>> this issue to a blocker since we need to do *something* about it
>>> before 4.3 is announced.
>>> Comments in the issue.
>>>
>>> -Yonik
>>> http://lucidworks.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Mark Miller <ma...@gmail.com>.
I committed a fix.
- Mark
On Apr 26, 2013, at 3:07 PM, Mark Miller <ma...@gmail.com> wrote:
> This is a nasty ugly ass bug with an annoying workaround. I'm committing a fix now.
>
> Hossman did bring it up to me a while ago, but I was too busy to comprehend it or look into it.
>
> - Mark
>
> On Apr 26, 2013, at 2:00 PM, Yonik Seeley <yo...@lucidworks.com> wrote:
>
>> On Wed, Apr 24, 2013 at 5:18 PM, Chris Hostetter
>> <ho...@fucit.org> wrote:
>>> FWIW: During my testing I did encounter one new bug: SOLR-4754, but since
>>> it has a workarround (and i have no idea yet what the underlying problem
>>> is to even try for a quick fix) I don't think it should block the release.
>>
>> Since it looks like there's going to be another respin, I've changed
>> this issue to a blocker since we need to do *something* about it
>> before 4.3 is announced.
>> Comments in the issue.
>>
>> -Yonik
>> http://lucidworks.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Mark Miller <ma...@gmail.com>.
This is a nasty ugly ass bug with an annoying workaround. I'm committing a fix now.
Hossman did bring it up to me a while ago, but I was too busy to comprehend it or look into it.
- Mark
On Apr 26, 2013, at 2:00 PM, Yonik Seeley <yo...@lucidworks.com> wrote:
> On Wed, Apr 24, 2013 at 5:18 PM, Chris Hostetter
> <ho...@fucit.org> wrote:
>> FWIW: During my testing I did encounter one new bug: SOLR-4754, but since
>> it has a workarround (and i have no idea yet what the underlying problem
>> is to even try for a quick fix) I don't think it should block the release.
>
> Since it looks like there's going to be another respin, I've changed
> this issue to a blocker since we need to do *something* about it
> before 4.3 is announced.
> Comments in the issue.
>
> -Yonik
> http://lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Yonik Seeley <yo...@lucidworks.com>.
On Wed, Apr 24, 2013 at 5:18 PM, Chris Hostetter
<ho...@fucit.org> wrote:
> FWIW: During my testing I did encounter one new bug: SOLR-4754, but since
> it has a workarround (and i have no idea yet what the underlying problem
> is to even try for a quick fix) I don't think it should block the release.
Since it looks like there's going to be another respin, I've changed
this issue to a blocker since we need to do *something* about it
before 4.3 is announced.
Comments in the issue.
-Yonik
http://lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Shai Erera <se...@gmail.com>.
+1 smoke tester happy here.
Shai
On Thu, Apr 25, 2013 at 12:18 AM, Chris Hostetter
<ho...@fucit.org>wrote:
>
> :
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
>
> +1 to releasing the artifacts with the following SHA1 signatures as
> Lucene/Solr 4.3.0...
>
> 3e1ec78f7b5bad2723dcf2f963d933758046afb9 *lucene-4.3.0-src.tgz
> 26843d53c86a9937d700f13f1d686adaca718244 *lucene-4.3.0.tgz
> 72b526a5aa21c7499954978a74e14ceac3a607ea *lucene-4.3.0.zip
> 9fd7abc7e478dbc5474658460da58ec360d6b1e4 *solr-4.3.0-src.tgz
> 5dca6da9f30830dc20163623b0a4f63749777f24 *solr-4.3.0.tgz
> ba6c86209614e3fe8cddeb3193bb8a09299ea457 *solr-4.3.0.zip
>
>
> FWIW: During my testing I did encounter one new bug: SOLR-4754, but since
> it has a workarround (and i have no idea yet what the underlying problem
> is to even try for a quick fix) I don't think it should block the release.
>
>
> -Hoss
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Chris Hostetter <ho...@fucit.org>.
: http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
+1 to releasing the artifacts with the following SHA1 signatures as
Lucene/Solr 4.3.0...
3e1ec78f7b5bad2723dcf2f963d933758046afb9 *lucene-4.3.0-src.tgz
26843d53c86a9937d700f13f1d686adaca718244 *lucene-4.3.0.tgz
72b526a5aa21c7499954978a74e14ceac3a607ea *lucene-4.3.0.zip
9fd7abc7e478dbc5474658460da58ec360d6b1e4 *solr-4.3.0-src.tgz
5dca6da9f30830dc20163623b0a4f63749777f24 *solr-4.3.0.tgz
ba6c86209614e3fe8cddeb3193bb8a09299ea457 *solr-4.3.0.zip
FWIW: During my testing I did encounter one new bug: SOLR-4754, but since
it has a workarround (and i have no idea yet what the underlying problem
is to even try for a quick fix) I don't think it should block the release.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Michael McCandless <lu...@mikemccandless.com>.
+1, smoke tester is happy.
Mike McCandless
http://blog.mikemccandless.com
On Tue, Apr 23, 2013 at 10:03 AM, Steve Rowe <sa...@gmail.com> wrote:
> +1, branch_4x smoke tester passes for me.
>
> On Apr 23, 2013, at 7:50 AM, Simon Willnauer <si...@gmail.com>
> wrote:
> > Here is a new RC candidate...
> >
> >
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
> >
> > here is my +1
> >
> > thanks for voting...
> >
> > simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Steve Rowe <sa...@gmail.com>.
+1, branch_4x smoke tester passes for me.
On Apr 23, 2013, at 7:50 AM, Simon Willnauer <si...@gmail.com> wrote:
> Here is a new RC candidate...
>
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
>
> here is my +1
>
> thanks for voting...
>
> simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Steve Rowe <sa...@gmail.com>.
I know why the two .wars are different:
The binary package Solr war's target chain is:
'package'->'create-package'->'dist'->'dist-war'->webapp:'dist'
The maven Solr war's target chain is:
'generate-maven-artifacts'->webapp:'dist-maven'->webapp:'dist'
So both create the war using webapp:'dist', but only 'dist-war' passes in a modified 'exclude.from.war' property definition (which is empty by default):
<property name="exclude.from.war" value="*slf4j*,log4j-*" />
I think the fix is to make the above the default setting, rather than passing in a non-default property value from 'dist-war'.
I'll make an issue.
Steve
On Apr 26, 2013, at 7:54 AM, Robert Muir <rc...@gmail.com> wrote:
> On Fri, Apr 26, 2013 at 7:50 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
> On Fri, Apr 26, 2013 at 7:34 AM, Robert Muir <rc...@gmail.com> wrote:
> > I would try to help fix it: but its not clear to me which 'package' is
> > correct or what happened to logging at all in 4.3
>
> Solr's CHANGES has a summary:
>
> * Slf4j/logging jars are no longer included in the Solr webapp. All logging
> jars are now in example/lib/ext. Changing logging impls is now as easy as
> updating the jars in this folder with those necessary for the logging impl
> you would like. If you are using another webapp container, these jars will
> need to go in the corresponding location for that container.
> In conjunction, the dist-excl-slf4j and dist-war-excl-slf4 build targets
> have been removed since they are redundent. See the Slf4j documentation,
> SOLR-3706, and SOLR-4651 for more details.
>
>
> As i said, this means the war in the TGZ is broken (and does not really work). And we still have the problem the war in maven disagrees with all this and does in fact contain the .jars.
>
> So it all looks like a disaster to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Apr 26, 2013 at 7:50 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
> On Fri, Apr 26, 2013 at 7:34 AM, Robert Muir <rc...@gmail.com> wrote:
> > I would try to help fix it: but its not clear to me which 'package' is
> > correct or what happened to logging at all in 4.3
>
> Solr's CHANGES has a summary:
>
> * Slf4j/logging jars are no longer included in the Solr webapp. All logging
> jars are now in example/lib/ext. Changing logging impls is now as easy as
> updating the jars in this folder with those necessary for the logging
> impl
> you would like. If you are using another webapp container, these jars
> will
> need to go in the corresponding location for that container.
> In conjunction, the dist-excl-slf4j and dist-war-excl-slf4 build targets
> have been removed since they are redundent. See the Slf4j documentation,
> SOLR-3706, and SOLR-4651 for more details.
>
>
As i said, this means the war in the TGZ is broken (and does not really
work). And we still have the problem the war in maven disagrees with all
this and does in fact contain the .jars.
So it all looks like a disaster to me.
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Mark Miller <ma...@gmail.com>.
It's a Maven problem as far as I'm concerned, and committers don't need to worry about Maven last we discussed, just the ones interested in Maven. So unless a Maven guy wants to address this, I'd say we are good to go!
I'd prefer Maven was downstream myself ;)
Everything else is as expected.
- Mark
On Apr 26, 2013, at 7:55 AM, Simon Willnauer <si...@gmail.com> wrote:
> I really love how you can reply without telling if we still have a
> problem or not :D
>
> simon
>
> On Fri, Apr 26, 2013 at 1:50 PM, Yonik Seeley <yo...@lucidworks.com> wrote:
>> On Fri, Apr 26, 2013 at 7:34 AM, Robert Muir <rc...@gmail.com> wrote:
>>> I would try to help fix it: but its not clear to me which 'package' is
>>> correct or what happened to logging at all in 4.3
>>
>> Solr's CHANGES has a summary:
>>
>> * Slf4j/logging jars are no longer included in the Solr webapp. All logging
>> jars are now in example/lib/ext. Changing logging impls is now as easy as
>> updating the jars in this folder with those necessary for the logging impl
>> you would like. If you are using another webapp container, these jars will
>> need to go in the corresponding location for that container.
>> In conjunction, the dist-excl-slf4j and dist-war-excl-slf4 build targets
>> have been removed since they are redundent. See the Slf4j documentation,
>> SOLR-3706, and SOLR-4651 for more details.
>>
>> -Yonik
>> http://lucidworks.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Mark Miller <ma...@gmail.com>.
Patch up.
https://issues.apache.org/jira/browse/SOLR-4771
- Mark
On Apr 26, 2013, at 11:34 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Unfortunately thats not possible with SFL4J: The „simplicity” of this framework is based on the fact that the class path can only conatin *one* logging implementation. If we ship with one we are back at the problem that users had before, the one from the WAR file took preference.
>
> The idea you had is not easily solveable, because you have no control on the classpath from inside the webapp (means at the time of loading the dispatch filter, the logging framework tries to initialize itself and you cannot change the *current* classloader so classes loaded later from the same webapp classloader will see the logging jar). So we can only stop working, but then with a good message. That’s the idea here.
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> From: Dyer, James [mailto:James.Dyer@ingramcontent.com]
> Sent: Friday, April 26, 2013 5:27 PM
> To: dev@lucene.apache.org
> Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3
>
> In the "catch", we could have it warn users that there is no external logging jar and then load a default implementation (commons-logging or even no-op). This would let users have a working .war if they do not include a logging jar but would make overriding this as easy as putting a logging jar in the classpath.
>
> James Dyer
> Ingram Content Group
> (615) 213-4311
>
> From: Steve Molloy [mailto:smolloy@opentext.com]
> Sent: Friday, April 26, 2013 10:05 AM
> To: dev@lucene.apache.org
> Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3
>
> That actually makes a lot of sense. J
>
> Steve Molloy
> Software Architect | Information Discovery & Analytics R&D
>
> <image001.gif>
>
> This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
>
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: April-26-13 11:03 AM
> To: dev@lucene.apache.org
> Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3
>
> Another idea: We should maybe change the ClassNotFoundException to something that makes a useful message:
> If you did not put a logging implementation outside into your servlet container’s lib dir, then solr should fail to start and throw a usefull Exception. Ideally this could be done on SolrDispatchFilter.init(), throwing a ServletException explaining that you need a logging implementation! This should be doable with some try-catch and initializing the logger in SolrDispatchFilter.init() – and SolrDispatchFilter should get the highest priority in web.xml, so its loaded first.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: Friday, April 26, 2013 4:56 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
>
> My problem is users will put the war in their container and get ClassNotFoundExceptions.
>
> Instead they should get some basic system.out.println-logger or some no-op implementation.
>
> 6 or 7 logging jars in our distribution and you are telling me it cant do simple stuff like this? What is the point of the 6-7 jars then?
>
> On Fri, Apr 26, 2013 at 10:51 AM, Steve Molloy <sm...@opentext.com> wrote:
> Have to agree with the not distributing 2 wars. But externalizing the logging jars is a great improvement for people integrating it. Repackaging the war to change logging framework to fit the rest of your code is far from being the best option. Adding the proper slf4j jars in your container’s classpath makes a lot more sense.
>
> Steve Molloy
> Software Architect | Information Discovery & Analytics R&D
>
> <image001.gif>
>
> This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
>
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: April-26-13 10:16 AM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
>
> I am taking it up with them. Right now before its ever released. I don't think our pmc should release two different solr-4.3.0.war files at different download locations. And I think the war we do release, should work.
>
> On Apr 26, 2013 10:06 AM, "Yonik Seeley" <yo...@lucidworks.com> wrote:
> On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rc...@gmail.com> wrote:
> > On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
> >> As to which WAR is correct, it's answered in the *first sentence* of
> >> what I quoted:
> >> "Slf4j/logging jars are no longer included in the Solr webapp"
> >
> >
> > Thats not "the answer", just because its in CHANGES.txt
>
> *shrug*
> I wasn't involved in that change, and I really don't care myself, but
> it's 100% crystal clear that removing the logging jars from the WAR
> was intentional (and hence the Maven artifacts are not as intended).
> If you think that the decision was incorrect, then take it up with
> those that made it.
>
> -Yonik
> http://lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Uwe Schindler <uw...@thetaphi.de>.
Unfortunately thats not possible with SFL4J: The „simplicity” of this framework is based on the fact that the class path can only conatin *one* logging implementation. If we ship with one we are back at the problem that users had before, the one from the WAR file took preference.
The idea you had is not easily solveable, because you have no control on the classpath from inside the webapp (means at the time of loading the dispatch filter, the logging framework tries to initialize itself and you cannot change the *current* classloader so classes loaded later from the same webapp classloader will see the logging jar). So we can only stop working, but then with a good message. That’s the idea here.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
<http://www.thetaphi.de/> http://www.thetaphi.de
eMail: uwe@thetaphi.de
From: Dyer, James [mailto:James.Dyer@ingramcontent.com]
Sent: Friday, April 26, 2013 5:27 PM
To: dev@lucene.apache.org
Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3
In the "catch", we could have it warn users that there is no external logging jar and then load a default implementation (commons-logging or even no-op). This would let users have a working .war if they do not include a logging jar but would make overriding this as easy as putting a logging jar in the classpath.
James Dyer
Ingram Content Group
(615) 213-4311
From: Steve Molloy [mailto:smolloy@opentext.com]
Sent: Friday, April 26, 2013 10:05 AM
To: dev@lucene.apache.org
Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3
That actually makes a lot of sense. J
Steve Molloy
Software Architect | Information Discovery & Analytics R&D
<http://www.opentext.com/2/email-signature-logo> http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif
This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
From: Uwe Schindler [mailto:uwe@thetaphi.de]
Sent: April-26-13 11:03 AM
To: dev@lucene.apache.org
Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3
Another idea: We should maybe change the ClassNotFoundException to something that makes a useful message:
If you did not put a logging implementation outside into your servlet container’s lib dir, then solr should fail to start and throw a usefull Exception. Ideally this could be done on SolrDispatchFilter.init(), throwing a ServletException explaining that you need a logging implementation! This should be doable with some try-catch and initializing the logger in SolrDispatchFilter.init() – and SolrDispatchFilter should get the highest priority in web.xml, so its loaded first.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
<http://www.thetaphi.de/> http://www.thetaphi.de
eMail: uwe@thetaphi.de
From: Robert Muir [mailto:rcmuir@gmail.com]
Sent: Friday, April 26, 2013 4:56 PM
To: dev@lucene.apache.org
Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
My problem is users will put the war in their container and get ClassNotFoundExceptions.
Instead they should get some basic system.out.println-logger or some no-op implementation.
6 or 7 logging jars in our distribution and you are telling me it cant do simple stuff like this? What is the point of the 6-7 jars then?
On Fri, Apr 26, 2013 at 10:51 AM, Steve Molloy <sm...@opentext.com> wrote:
Have to agree with the not distributing 2 wars. But externalizing the logging jars is a great improvement for people integrating it. Repackaging the war to change logging framework to fit the rest of your code is far from being the best option. Adding the proper slf4j jars in your container’s classpath makes a lot more sense.
Steve Molloy
Software Architect | Information Discovery & Analytics R&D
<http://www.opentext.com/2/email-signature-logo> http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif
This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
From: Robert Muir [mailto:rcmuir@gmail.com]
Sent: April-26-13 10:16 AM
To: dev@lucene.apache.org
Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
I am taking it up with them. Right now before its ever released. I don't think our pmc should release two different solr-4.3.0.war files at different download locations. And I think the war we do release, should work.
On Apr 26, 2013 10:06 AM, "Yonik Seeley" <yo...@lucidworks.com> wrote:
On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rc...@gmail.com> wrote:
> On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
>> As to which WAR is correct, it's answered in the *first sentence* of
>> what I quoted:
>> "Slf4j/logging jars are no longer included in the Solr webapp"
>
>
> Thats not "the answer", just because its in CHANGES.txt
*shrug*
I wasn't involved in that change, and I really don't care myself, but
it's 100% crystal clear that removing the logging jars from the WAR
was intentional (and hence the Maven artifacts are not as intended).
If you think that the decision was incorrect, then take it up with
those that made it.
-Yonik
http://lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Lucene Solr 4.3.0 RC3
Posted by "Dyer, James" <Ja...@ingramcontent.com>.
In the "catch", we could have it warn users that there is no external logging jar and then load a default implementation (commons-logging or even no-op). This would let users have a working .war if they do not include a logging jar but would make overriding this as easy as putting a logging jar in the classpath.
James Dyer
Ingram Content Group
(615) 213-4311
From: Steve Molloy [mailto:smolloy@opentext.com]
Sent: Friday, April 26, 2013 10:05 AM
To: dev@lucene.apache.org
Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3
That actually makes a lot of sense. ☺
Steve Molloy
Software Architect | Information Discovery & Analytics R&D
[cid:image001.gif@01CE4268.8A5A9FB0]<http://www.opentext.com/2/email-signature-logo>
This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
From: Uwe Schindler [mailto:uwe@thetaphi.de]
Sent: April-26-13 11:03 AM
To: dev@lucene.apache.org
Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3
Another idea: We should maybe change the ClassNotFoundException to something that makes a useful message:
If you did not put a logging implementation outside into your servlet container’s lib dir, then solr should fail to start and throw a usefull Exception. Ideally this could be done on SolrDispatchFilter.init(), throwing a ServletException explaining that you need a logging implementation! This should be doable with some try-catch and initializing the logger in SolrDispatchFilter.init() – and SolrDispatchFilter should get the highest priority in web.xml, so its loaded first.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de<http://www.thetaphi.de/>
eMail: uwe@thetaphi.de<ma...@thetaphi.de>
From: Robert Muir [mailto:rcmuir@gmail.com]
Sent: Friday, April 26, 2013 4:56 PM
To: dev@lucene.apache.org<ma...@lucene.apache.org>
Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
My problem is users will put the war in their container and get ClassNotFoundExceptions.
Instead they should get some basic system.out.println-logger or some no-op implementation.
6 or 7 logging jars in our distribution and you are telling me it cant do simple stuff like this? What is the point of the 6-7 jars then?
On Fri, Apr 26, 2013 at 10:51 AM, Steve Molloy <sm...@opentext.com>> wrote:
Have to agree with the not distributing 2 wars. But externalizing the logging jars is a great improvement for people integrating it. Repackaging the war to change logging framework to fit the rest of your code is far from being the best option. Adding the proper slf4j jars in your container’s classpath makes a lot more sense.
Steve Molloy
Software Architect | Information Discovery & Analytics R&D
[cid:image001.gif@01CE4268.8A5A9FB0]<http://www.opentext.com/2/email-signature-logo>
This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
From: Robert Muir [mailto:rcmuir@gmail.com<ma...@gmail.com>]
Sent: April-26-13 10:16 AM
To: dev@lucene.apache.org<ma...@lucene.apache.org>
Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
I am taking it up with them. Right now before its ever released. I don't think our pmc should release two different solr-4.3.0.war files at different download locations. And I think the war we do release, should work.
On Apr 26, 2013 10:06 AM, "Yonik Seeley" <yo...@lucidworks.com>> wrote:
On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rc...@gmail.com>> wrote:
> On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com>> wrote:
>> As to which WAR is correct, it's answered in the *first sentence* of
>> what I quoted:
>> "Slf4j/logging jars are no longer included in the Solr webapp"
>
>
> Thats not "the answer", just because its in CHANGES.txt
*shrug*
I wasn't involved in that change, and I really don't care myself, but
it's 100% crystal clear that removing the logging jars from the WAR
was intentional (and hence the Maven artifacts are not as intended).
If you think that the decision was incorrect, then take it up with
those that made it.
-Yonik
http://lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org<ma...@lucene.apache.org>
For additional commands, e-mail: dev-help@lucene.apache.org<ma...@lucene.apache.org>
RE: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Steve Molloy <sm...@opentext.com>.
That actually makes a lot of sense. ☺
Steve Molloy
Software Architect | Information Discovery & Analytics R&D
[http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif]<http://www.opentext.com/2/email-signature-logo>
This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
From: Uwe Schindler [mailto:uwe@thetaphi.de]
Sent: April-26-13 11:03 AM
To: dev@lucene.apache.org
Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3
Another idea: We should maybe change the ClassNotFoundException to something that makes a useful message:
If you did not put a logging implementation outside into your servlet container’s lib dir, then solr should fail to start and throw a usefull Exception. Ideally this could be done on SolrDispatchFilter.init(), throwing a ServletException explaining that you need a logging implementation! This should be doable with some try-catch and initializing the logger in SolrDispatchFilter.init() – and SolrDispatchFilter should get the highest priority in web.xml, so its loaded first.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de<http://www.thetaphi.de/>
eMail: uwe@thetaphi.de<ma...@thetaphi.de>
From: Robert Muir [mailto:rcmuir@gmail.com]
Sent: Friday, April 26, 2013 4:56 PM
To: dev@lucene.apache.org<ma...@lucene.apache.org>
Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
My problem is users will put the war in their container and get ClassNotFoundExceptions.
Instead they should get some basic system.out.println-logger or some no-op implementation.
6 or 7 logging jars in our distribution and you are telling me it cant do simple stuff like this? What is the point of the 6-7 jars then?
On Fri, Apr 26, 2013 at 10:51 AM, Steve Molloy <sm...@opentext.com>> wrote:
Have to agree with the not distributing 2 wars. But externalizing the logging jars is a great improvement for people integrating it. Repackaging the war to change logging framework to fit the rest of your code is far from being the best option. Adding the proper slf4j jars in your container’s classpath makes a lot more sense.
Steve Molloy
Software Architect | Information Discovery & Analytics R&D
[http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif]<http://www.opentext.com/2/email-signature-logo>
This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
From: Robert Muir [mailto:rcmuir@gmail.com<ma...@gmail.com>]
Sent: April-26-13 10:16 AM
To: dev@lucene.apache.org<ma...@lucene.apache.org>
Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
I am taking it up with them. Right now before its ever released. I don't think our pmc should release two different solr-4.3.0.war files at different download locations. And I think the war we do release, should work.
On Apr 26, 2013 10:06 AM, "Yonik Seeley" <yo...@lucidworks.com>> wrote:
On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rc...@gmail.com>> wrote:
> On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com>> wrote:
>> As to which WAR is correct, it's answered in the *first sentence* of
>> what I quoted:
>> "Slf4j/logging jars are no longer included in the Solr webapp"
>
>
> Thats not "the answer", just because its in CHANGES.txt
*shrug*
I wasn't involved in that change, and I really don't care myself, but
it's 100% crystal clear that removing the logging jars from the WAR
was intentional (and hence the Maven artifacts are not as intended).
If you think that the decision was incorrect, then take it up with
those that made it.
-Yonik
http://lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org<ma...@lucene.apache.org>
For additional commands, e-mail: dev-help@lucene.apache.org<ma...@lucene.apache.org>
RE: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Uwe Schindler <uw...@thetaphi.de>.
Yeah. I want to "catch" the common case. Somebody downloads the war from Maven and deploys it in his Tomcat. In that case the message should be displayed on SolrDispatchFilter startup. If the other servlets in Solr don’t use a logging impl, we are fine... Otherwise we can make some class LogInitializer and that’s used from all servlets to instantiate the logging framework for the private "log" field.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Mark Miller [mailto:markrmiller@gmail.com]
> Sent: Friday, April 26, 2013 5:14 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
>
> +1 - if we can manage a more useful message, that would be a good
> improvement.
>
> bq. and SolrDispatchFilter should get the highest priority in web.xml, so its
> loaded first.
>
> The problem is, we don't really control that - especially in the case when
> someone is just trying to suck up the war.
>
> - Mark
>
> On Apr 26, 2013, at 11:02 AM, "Uwe Schindler" <uw...@thetaphi.de> wrote:
>
> > Another idea: We should maybe change the ClassNotFoundException to
> something that makes a useful message:
> > If you did not put a logging implementation outside into your servlet
> container’s lib dir, then solr should fail to start and throw a usefull Exception.
> Ideally this could be done on SolrDispatchFilter.init(), throwing a
> ServletException explaining that you need a logging implementation! This
> should be doable with some try-catch and initializing the logger in
> SolrDispatchFilter.init() – and SolrDispatchFilter should get the highest
> priority in web.xml, so its loaded first.
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> > From: Robert Muir [mailto:rcmuir@gmail.com]
> > Sent: Friday, April 26, 2013 4:56 PM
> > To: dev@lucene.apache.org
> > Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
> >
> > My problem is users will put the war in their container and get
> ClassNotFoundExceptions.
> >
> > Instead they should get some basic system.out.println-logger or some no-
> op implementation.
> >
> > 6 or 7 logging jars in our distribution and you are telling me it cant do simple
> stuff like this? What is the point of the 6-7 jars then?
> >
> > On Fri, Apr 26, 2013 at 10:51 AM, Steve Molloy <sm...@opentext.com>
> wrote:
> > Have to agree with the not distributing 2 wars. But externalizing the logging
> jars is a great improvement for people integrating it. Repackaging the war to
> change logging framework to fit the rest of your code is far from being the
> best option. Adding the proper slf4j jars in your container’s classpath makes a
> lot more sense.
> >
> > Steve Molloy
> > Software Architect | Information Discovery & Analytics R&D
> >
> > <image001.gif>
> >
> > This email message is confidential, may be privileged, and is intended for
> the exclusive use of the addressee. Any other person is strictly prohibited
> from disclosing or reproducing it. If the addressee cannot be reached or is
> unknown to you, please inform the sender by return email and delete this
> email message and all copies immediately.
> >
> > From: Robert Muir [mailto:rcmuir@gmail.com]
> > Sent: April-26-13 10:16 AM
> > To: dev@lucene.apache.org
> > Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
> >
> > I am taking it up with them. Right now before its ever released. I don't think
> our pmc should release two different solr-4.3.0.war files at different
> download locations. And I think the war we do release, should work.
> >
> > On Apr 26, 2013 10:06 AM, "Yonik Seeley" <yo...@lucidworks.com> wrote:
> > On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rc...@gmail.com> wrote:
> > > On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com>
> wrote:
> > >> As to which WAR is correct, it's answered in the *first sentence*
> > >> of what I quoted:
> > >> "Slf4j/logging jars are no longer included in the Solr webapp"
> > >
> > >
> > > Thats not "the answer", just because its in CHANGES.txt
> >
> > *shrug*
> > I wasn't involved in that change, and I really don't care myself, but
> > it's 100% crystal clear that removing the logging jars from the WAR
> > was intentional (and hence the Maven artifacts are not as intended).
> > If you think that the decision was incorrect, then take it up with
> > those that made it.
> >
> > -Yonik
> > http://lucidworks.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Mark Miller <ma...@gmail.com>.
+1 - if we can manage a more useful message, that would be a good improvement.
bq. and SolrDispatchFilter should get the highest priority in web.xml, so its loaded first.
The problem is, we don't really control that - especially in the case when someone is just trying to suck up the war.
- Mark
On Apr 26, 2013, at 11:02 AM, "Uwe Schindler" <uw...@thetaphi.de> wrote:
> Another idea: We should maybe change the ClassNotFoundException to something that makes a useful message:
> If you did not put a logging implementation outside into your servlet container’s lib dir, then solr should fail to start and throw a usefull Exception. Ideally this could be done on SolrDispatchFilter.init(), throwing a ServletException explaining that you need a logging implementation! This should be doable with some try-catch and initializing the logger in SolrDispatchFilter.init() – and SolrDispatchFilter should get the highest priority in web.xml, so its loaded first.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: Friday, April 26, 2013 4:56 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
>
> My problem is users will put the war in their container and get ClassNotFoundExceptions.
>
> Instead they should get some basic system.out.println-logger or some no-op implementation.
>
> 6 or 7 logging jars in our distribution and you are telling me it cant do simple stuff like this? What is the point of the 6-7 jars then?
>
> On Fri, Apr 26, 2013 at 10:51 AM, Steve Molloy <sm...@opentext.com> wrote:
> Have to agree with the not distributing 2 wars. But externalizing the logging jars is a great improvement for people integrating it. Repackaging the war to change logging framework to fit the rest of your code is far from being the best option. Adding the proper slf4j jars in your container’s classpath makes a lot more sense.
>
> Steve Molloy
> Software Architect | Information Discovery & Analytics R&D
>
> <image001.gif>
>
> This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
>
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: April-26-13 10:16 AM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
>
> I am taking it up with them. Right now before its ever released. I don't think our pmc should release two different solr-4.3.0.war files at different download locations. And I think the war we do release, should work.
>
> On Apr 26, 2013 10:06 AM, "Yonik Seeley" <yo...@lucidworks.com> wrote:
> On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rc...@gmail.com> wrote:
> > On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
> >> As to which WAR is correct, it's answered in the *first sentence* of
> >> what I quoted:
> >> "Slf4j/logging jars are no longer included in the Solr webapp"
> >
> >
> > Thats not "the answer", just because its in CHANGES.txt
>
> *shrug*
> I wasn't involved in that change, and I really don't care myself, but
> it's 100% crystal clear that removing the logging jars from the WAR
> was intentional (and hence the Maven artifacts are not as intended).
> If you think that the decision was incorrect, then take it up with
> those that made it.
>
> -Yonik
> http://lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Uwe Schindler <uw...@thetaphi.de>.
Another idea: We should maybe change the ClassNotFoundException to something that makes a useful message:
If you did not put a logging implementation outside into your servlet container’s lib dir, then solr should fail to start and throw a usefull Exception. Ideally this could be done on SolrDispatchFilter.init(), throwing a ServletException explaining that you need a logging implementation! This should be doable with some try-catch and initializing the logger in SolrDispatchFilter.init() – and SolrDispatchFilter should get the highest priority in web.xml, so its loaded first.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
<http://www.thetaphi.de/> http://www.thetaphi.de
eMail: uwe@thetaphi.de
From: Robert Muir [mailto:rcmuir@gmail.com]
Sent: Friday, April 26, 2013 4:56 PM
To: dev@lucene.apache.org
Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
My problem is users will put the war in their container and get ClassNotFoundExceptions.
Instead they should get some basic system.out.println-logger or some no-op implementation.
6 or 7 logging jars in our distribution and you are telling me it cant do simple stuff like this? What is the point of the 6-7 jars then?
On Fri, Apr 26, 2013 at 10:51 AM, Steve Molloy <sm...@opentext.com> wrote:
Have to agree with the not distributing 2 wars. But externalizing the logging jars is a great improvement for people integrating it. Repackaging the war to change logging framework to fit the rest of your code is far from being the best option. Adding the proper slf4j jars in your container’s classpath makes a lot more sense.
Steve Molloy
Software Architect | Information Discovery & Analytics R&D
<http://www.opentext.com/2/email-signature-logo> http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif
This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
From: Robert Muir [mailto:rcmuir@gmail.com]
Sent: April-26-13 10:16 AM
To: dev@lucene.apache.org
Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
I am taking it up with them. Right now before its ever released. I don't think our pmc should release two different solr-4.3.0.war files at different download locations. And I think the war we do release, should work.
On Apr 26, 2013 10:06 AM, "Yonik Seeley" <yo...@lucidworks.com> wrote:
On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rc...@gmail.com> wrote:
> On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
>> As to which WAR is correct, it's answered in the *first sentence* of
>> what I quoted:
>> "Slf4j/logging jars are no longer included in the Solr webapp"
>
>
> Thats not "the answer", just because its in CHANGES.txt
*shrug*
I wasn't involved in that change, and I really don't care myself, but
it's 100% crystal clear that removing the logging jars from the WAR
was intentional (and hence the Maven artifacts are not as intended).
If you think that the decision was incorrect, then take it up with
those that made it.
-Yonik
http://lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Robert Muir <rc...@gmail.com>.
My problem is users will put the war in their container and get
ClassNotFoundExceptions.
Instead they should get some basic system.out.println-logger or some no-op
implementation.
6 or 7 logging jars in our distribution and you are telling me it cant do
simple stuff like this? What is the point of the 6-7 jars then?
On Fri, Apr 26, 2013 at 10:51 AM, Steve Molloy <sm...@opentext.com> wrote:
> Have to agree with the not distributing 2 wars. But externalizing the
> logging jars is a great improvement for people integrating it. Repackaging
> the war to change logging framework to fit the rest of your code is far
> from being the best option. Adding the proper slf4j jars in your
> container’s classpath makes a lot more sense.****
>
> ** **
>
> *Steve Molloy*
> Software Architect | Information Discovery & Analytics R&D****
>
> [image: http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif]<http://www.opentext.com/2/email-signature-logo>
>
> This email message is confidential, may be privileged, and is intended for
> the exclusive use of the addressee. Any other person is strictly prohibited
> from disclosing or reproducing it. If the addressee cannot be reached or is
> unknown to you, please inform the sender by return email and delete this
> email message and all copies immediately.****
>
> ** **
>
> *From:* Robert Muir [mailto:rcmuir@gmail.com]
> *Sent:* April-26-13 10:16 AM
> *To:* dev@lucene.apache.org
> *Subject:* Re: [VOTE] Lucene Solr 4.3.0 RC3****
>
> ** **
>
> I am taking it up with them. Right now before its ever released. I don't
> think our pmc should release two different solr-4.3.0.war files at
> different download locations. And I think the war we do release, should
> work.****
>
> On Apr 26, 2013 10:06 AM, "Yonik Seeley" <yo...@lucidworks.com> wrote:****
>
> On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rc...@gmail.com> wrote:
> > On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com>
> wrote:
> >> As to which WAR is correct, it's answered in the *first sentence* of
> >> what I quoted:
> >> "Slf4j/logging jars are no longer included in the Solr webapp"
> >
> >
> > Thats not "the answer", just because its in CHANGES.txt
>
> *shrug*
> I wasn't involved in that change, and I really don't care myself, but
> it's 100% crystal clear that removing the logging jars from the WAR
> was intentional (and hence the Maven artifacts are not as intended).
> If you think that the decision was incorrect, then take it up with
> those that made it.
>
> -Yonik
> http://lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org****
>
RE: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Steve Molloy <sm...@opentext.com>.
Have to agree with the not distributing 2 wars. But externalizing the logging jars is a great improvement for people integrating it. Repackaging the war to change logging framework to fit the rest of your code is far from being the best option. Adding the proper slf4j jars in your container’s classpath makes a lot more sense.
Steve Molloy
Software Architect | Information Discovery & Analytics R&D
[http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif]<http://www.opentext.com/2/email-signature-logo>
This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
From: Robert Muir [mailto:rcmuir@gmail.com]
Sent: April-26-13 10:16 AM
To: dev@lucene.apache.org
Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3
I am taking it up with them. Right now before its ever released. I don't think our pmc should release two different solr-4.3.0.war files at different download locations. And I think the war we do release, should work.
On Apr 26, 2013 10:06 AM, "Yonik Seeley" <yo...@lucidworks.com>> wrote:
On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rc...@gmail.com>> wrote:
> On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com>> wrote:
>> As to which WAR is correct, it's answered in the *first sentence* of
>> what I quoted:
>> "Slf4j/logging jars are no longer included in the Solr webapp"
>
>
> Thats not "the answer", just because its in CHANGES.txt
*shrug*
I wasn't involved in that change, and I really don't care myself, but
it's 100% crystal clear that removing the logging jars from the WAR
was intentional (and hence the Maven artifacts are not as intended).
If you think that the decision was incorrect, then take it up with
those that made it.
-Yonik
http://lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org<ma...@lucene.apache.org>
For additional commands, e-mail: dev-help@lucene.apache.org<ma...@lucene.apache.org>
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Robert Muir <rc...@gmail.com>.
I am taking it up with them. Right now before its ever released. I don't
think our pmc should release two different solr-4.3.0.war files at
different download locations. And I think the war we do release, should
work.
On Apr 26, 2013 10:06 AM, "Yonik Seeley" <yo...@lucidworks.com> wrote:
> On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rc...@gmail.com> wrote:
> > On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com>
> wrote:
> >> As to which WAR is correct, it's answered in the *first sentence* of
> >> what I quoted:
> >> "Slf4j/logging jars are no longer included in the Solr webapp"
> >
> >
> > Thats not "the answer", just because its in CHANGES.txt
>
> *shrug*
> I wasn't involved in that change, and I really don't care myself, but
> it's 100% crystal clear that removing the logging jars from the WAR
> was intentional (and hence the Maven artifacts are not as intended).
> If you think that the decision was incorrect, then take it up with
> those that made it.
>
> -Yonik
> http://lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Yonik Seeley <yo...@lucidworks.com>.
On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rc...@gmail.com> wrote:
> On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
>> As to which WAR is correct, it's answered in the *first sentence* of
>> what I quoted:
>> "Slf4j/logging jars are no longer included in the Solr webapp"
>
>
> Thats not "the answer", just because its in CHANGES.txt
*shrug*
I wasn't involved in that change, and I really don't care myself, but
it's 100% crystal clear that removing the logging jars from the WAR
was intentional (and hence the Maven artifacts are not as intended).
If you think that the decision was incorrect, then take it up with
those that made it.
-Yonik
http://lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Mark Miller <ma...@gmail.com>.
On Apr 26, 2013, at 9:36 AM, Robert Muir <rc...@gmail.com> wrote:
> In my opinion shipping a war that does not actually work is broken, because its really no war at all.
We don't ship a war, we ship Solr. To use our war outside of what we ship, setup the logging as CHANGES says to do. It's actually all much easier and nicer than it was in the past.
It's all correct and many committers where involved in the changes.
Nothing is broken here.
- Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
> On Fri, Apr 26, 2013 at 7:55 AM, Simon Willnauer
> <si...@gmail.com> wrote:
> > I really love how you can reply without telling if we still have a
> > problem or not :D
>
> I was responding to the "what happened to logging at all in 4.3".
>
> As to which WAR is correct, it's answered in the *first sentence* of
> what I quoted:
> "Slf4j/logging jars are no longer included in the Solr webapp"
>
Thats not "the answer", just because its in CHANGES.txt
In my opinion shipping a war that does not actually work is broken, because
its really no war at all.
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Yonik Seeley <yo...@lucidworks.com>.
On Fri, Apr 26, 2013 at 7:55 AM, Simon Willnauer
<si...@gmail.com> wrote:
> I really love how you can reply without telling if we still have a
> problem or not :D
I was responding to the "what happened to logging at all in 4.3".
As to which WAR is correct, it's answered in the *first sentence* of
what I quoted:
"Slf4j/logging jars are no longer included in the Solr webapp"
-Yonik
http://lucidworks.com
> On Fri, Apr 26, 2013 at 1:50 PM, Yonik Seeley <yo...@lucidworks.com> wrote:
>> On Fri, Apr 26, 2013 at 7:34 AM, Robert Muir <rc...@gmail.com> wrote:
>>> I would try to help fix it: but its not clear to me which 'package' is
>>> correct or what happened to logging at all in 4.3
>>
>> Solr's CHANGES has a summary:
>>
>> * Slf4j/logging jars are no longer included in the Solr webapp. All logging
>> jars are now in example/lib/ext. Changing logging impls is now as easy as
>> updating the jars in this folder with those necessary for the logging impl
>> you would like. If you are using another webapp container, these jars will
>> need to go in the corresponding location for that container.
>> In conjunction, the dist-excl-slf4j and dist-war-excl-slf4 build targets
>> have been removed since they are redundent. See the Slf4j documentation,
>> SOLR-3706, and SOLR-4651 for more details.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Simon Willnauer <si...@gmail.com>.
I really love how you can reply without telling if we still have a
problem or not :D
simon
On Fri, Apr 26, 2013 at 1:50 PM, Yonik Seeley <yo...@lucidworks.com> wrote:
> On Fri, Apr 26, 2013 at 7:34 AM, Robert Muir <rc...@gmail.com> wrote:
>> I would try to help fix it: but its not clear to me which 'package' is
>> correct or what happened to logging at all in 4.3
>
> Solr's CHANGES has a summary:
>
> * Slf4j/logging jars are no longer included in the Solr webapp. All logging
> jars are now in example/lib/ext. Changing logging impls is now as easy as
> updating the jars in this folder with those necessary for the logging impl
> you would like. If you are using another webapp container, these jars will
> need to go in the corresponding location for that container.
> In conjunction, the dist-excl-slf4j and dist-war-excl-slf4 build targets
> have been removed since they are redundent. See the Slf4j documentation,
> SOLR-3706, and SOLR-4651 for more details.
>
> -Yonik
> http://lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Yonik Seeley <yo...@lucidworks.com>.
On Fri, Apr 26, 2013 at 7:34 AM, Robert Muir <rc...@gmail.com> wrote:
> I would try to help fix it: but its not clear to me which 'package' is
> correct or what happened to logging at all in 4.3
Solr's CHANGES has a summary:
* Slf4j/logging jars are no longer included in the Solr webapp. All logging
jars are now in example/lib/ext. Changing logging impls is now as easy as
updating the jars in this folder with those necessary for the logging impl
you would like. If you are using another webapp container, these jars will
need to go in the corresponding location for that container.
In conjunction, the dist-excl-slf4j and dist-war-excl-slf4 build targets
have been removed since they are redundent. See the Slf4j documentation,
SOLR-3706, and SOLR-4651 for more details.
-Yonik
http://lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Apr 26, 2013 at 7:06 AM, Michael McCandless <
lucene@mikemccandless.com> wrote:
> On Fri, Apr 26, 2013 at 6:57 AM, Robert Muir <rc...@gmail.com> wrote:
> >
> > i dont understand logging at all... needing 6 or 7 jars to
> "System.out.println" is the most ridiculous thing in the world to me. So
> someone else will have to comment about "which one is right", the .tgz or
> maven
> >
> > but it seems totally broken for the war to have a bunch of extra jars in
> maven that it doesnt have in the tgz. If a user has a problem with logging
> (and since all these jars changed, i feel this is a possibility), no one
> will have a clue how to proceed. We could only ask... 'Which 4.3 are you
> using? 4.3-MAVEN or 4.3-TGZ?'
> >
> > Personally i'm -1 for us releasing different artifacts in maven than in
> the tgz because i strongly believe we should only have "one release" and
> not release different shit to different places. I'd rather us just not
> release any maven artifacts at all than do this (if you have no time to
> respin, just remove the maven artifacts from the RC and you will get my +1).
>
> I agree ... I think we should fix this and build a new RC.
>
I would try to help fix it: but its not clear to me which 'package' is
correct or what happened to logging at all in 4.3
The TGZ seems broken that it has no logging jars at all but solr code
relies upon it, so there is no way in hell thats actually working. This
means that .war file is totally unusable by itself... I think thats broken?
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Fri, Apr 26, 2013 at 6:57 AM, Robert Muir <rc...@gmail.com> wrote:
>
> i dont understand logging at all... needing 6 or 7 jars to "System.out.println" is the most ridiculous thing in the world to me. So someone else will have to comment about "which one is right", the .tgz or maven
>
> but it seems totally broken for the war to have a bunch of extra jars in maven that it doesnt have in the tgz. If a user has a problem with logging (and since all these jars changed, i feel this is a possibility), no one will have a clue how to proceed. We could only ask... 'Which 4.3 are you using? 4.3-MAVEN or 4.3-TGZ?'
>
> Personally i'm -1 for us releasing different artifacts in maven than in the tgz because i strongly believe we should only have "one release" and not release different shit to different places. I'd rather us just not release any maven artifacts at all than do this (if you have no time to respin, just remove the maven artifacts from the RC and you will get my +1).
I agree ... I think we should fix this and build a new RC.
Maven really should package the same things as the normal release
(this is why it REALLY should be a downstream thing...... but we've
had THAT discussion too many times already).
I'll fix the smokeTester to detect this (SOLR-4766).
Mike McCandless
http://blog.mikemccandless.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Robert Muir <rc...@gmail.com>.
i dont understand logging at all... needing 6 or 7 jars to
"System.out.println" is the most ridiculous thing in the world to me. So
someone else will have to comment about "which one is right", the .tgz or
maven
but it seems totally broken for the war to have a bunch of extra jars in
maven that it doesnt have in the tgz. If a user has a problem with logging
(and since all these jars changed, i feel this is a possibility), no one
will have a clue how to proceed. We could only ask... 'Which 4.3 are you
using? 4.3-MAVEN or 4.3-TGZ?'
Personally i'm -1 for us releasing different artifacts in maven than in the
tgz because i strongly believe we should only have "one release" and not
release different shit to different places. I'd rather us just not release
any maven artifacts at all than do this (if you have no time to respin,
just remove the maven artifacts from the RC and you will get my +1).
On Fri, Apr 26, 2013 at 4:49 AM, Simon Willnauer
<si...@gmail.com>wrote:
> can someone from solr land comment on the SLF4j issue? I am not sure I
> can make a decision if that should block a release.
>
> thanks,
>
> simon
>
> On Thu, Apr 25, 2013 at 11:07 PM, Ryan Ernst <ry...@iernst.net> wrote:
> > -1
> >
> > It seems SLF4j packaging is busted? I thought I remembered slf4j jars
> were
> > removed from the war, in favor of putting them in the classpath. But I
> see
> > slf4j jars in the maven war file, but not in the tgz war file.
> >
> >
> > On Thu, Apr 25, 2013 at 10:19 AM, Mark Miller <ma...@gmail.com>
> wrote:
> >>
> >> +1
> >>
> >> - Mark
> >>
> >> On Apr 23, 2013, at 7:50 AM, Simon Willnauer <simon.willnauer@gmail.com
> >
> >> wrote:
> >>
> >> > Here is a new RC candidate...
> >> >
> >> >
> >> >
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
> >> >
> >> > here is my +1
> >> >
> >> > thanks for voting...
> >> >
> >> > simon
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Simon Willnauer <si...@gmail.com>.
can someone from solr land comment on the SLF4j issue? I am not sure I
can make a decision if that should block a release.
thanks,
simon
On Thu, Apr 25, 2013 at 11:07 PM, Ryan Ernst <ry...@iernst.net> wrote:
> -1
>
> It seems SLF4j packaging is busted? I thought I remembered slf4j jars were
> removed from the war, in favor of putting them in the classpath. But I see
> slf4j jars in the maven war file, but not in the tgz war file.
>
>
> On Thu, Apr 25, 2013 at 10:19 AM, Mark Miller <ma...@gmail.com> wrote:
>>
>> +1
>>
>> - Mark
>>
>> On Apr 23, 2013, at 7:50 AM, Simon Willnauer <si...@gmail.com>
>> wrote:
>>
>> > Here is a new RC candidate...
>> >
>> >
>> > http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
>> >
>> > here is my +1
>> >
>> > thanks for voting...
>> >
>> > simon
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Ryan Ernst <ry...@iernst.net>.
-1
It seems SLF4j packaging is busted? I thought I remembered slf4j jars were
removed from the war, in favor of putting them in the classpath. But I see
slf4j jars in the maven war file, but not in the tgz war file.
On Thu, Apr 25, 2013 at 10:19 AM, Mark Miller <ma...@gmail.com> wrote:
> +1
>
> - Mark
>
> On Apr 23, 2013, at 7:50 AM, Simon Willnauer <si...@gmail.com>
> wrote:
>
> > Here is a new RC candidate...
> >
> >
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
> >
> > here is my +1
> >
> > thanks for voting...
> >
> > simon
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Mark Miller <ma...@gmail.com>.
+1
- Mark
On Apr 23, 2013, at 7:50 AM, Simon Willnauer <si...@gmail.com> wrote:
> Here is a new RC candidate...
>
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
>
> here is my +1
>
> thanks for voting...
>
> simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Martijn v Groningen <ma...@gmail.com>.
+1, smoker is happy
On 24 April 2013 10:03, Tommaso Teofili <to...@gmail.com> wrote:
> +1, smoke tests pass.
>
> Tommaso
>
>
> 2013/4/23 Simon Willnauer <si...@gmail.com>
>
>> Here is a new RC candidate...
>>
>>
>> http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
>>
>> here is my +1
>>
>> thanks for voting...
>>
>> simon
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
--
Met vriendelijke groet,
Martijn van Groningen
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Tommaso Teofili <to...@gmail.com>.
+1, smoke tests pass.
Tommaso
2013/4/23 Simon Willnauer <si...@gmail.com>
> Here is a new RC candidate...
>
>
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
>
> here is my +1
>
> thanks for voting...
>
> simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [VOTE] Lucene Solr 4.3.0 RC3
Posted by Jack Krupansky <ja...@basetechnology.com>.
+1
It's nice to have EdgeNGramFilter doing the proper thing with token
position - all tokens are at the same position now.
-- Jack Krupansky
-----Original Message-----
From: Simon Willnauer
Sent: Tuesday, April 23, 2013 7:50 AM
To: dev@lucene.apache.org
Subject: [VOTE] Lucene Solr 4.3.0 RC3
Here is a new RC candidate...
http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
here is my +1
thanks for voting...
simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org