subject:"\[VOTE\] Lucene Solr 4.3.0 RC3"

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
simon.willna...@gmail.comwrote:

 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 r...@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 markrmil...@gmail.com
 wrote:
 
  +1
 
  - Mark
 
  On Apr 23, 2013, at 7:50 AM, Simon Willnauer simon.willna...@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-unsubscr...@lucene.apache.org
   For additional commands, e-mail: dev-h...@lucene.apache.org
  
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene Solr 4.3.0 RC3

2013-04-26 Thread Michael McCandless

On Fri, Apr 26, 2013 at 6:57 AM, Robert Muir rcm...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene Solr 4.3.0 RC3

On Fri, Apr 26, 2013 at 7:06 AM, Michael McCandless 
luc...@mikemccandless.com wrote:

 On Fri, Apr 26, 2013 at 6:57 AM, Robert Muir rcm...@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

On Fri, Apr 26, 2013 at 7:34 AM, Robert Muir rcm...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene Solr 4.3.0 RC3

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 rcm...@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

2013-04-26 Thread Simon Willnauer

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 rcm...@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-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene Solr 4.3.0 RC3

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 simon.willna...@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 rcm...@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-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene Solr 4.3.0 RC3

On Fri, Apr 26, 2013 at 7:55 AM, Simon Willnauer
simon.willna...@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 rcm...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene Solr 4.3.0 RC3

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
 simon.willna...@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


On Apr 26, 2013, at 9:36 AM, Robert Muir rcm...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene Solr 4.3.0 RC3

On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir rcm...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene Solr 4.3.0 RC3

2013-04-26 Thread Steve Rowe

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 rcm...@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 rcm...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

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 rcm...@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-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [VOTE] Lucene Solr 4.3.0 RC3

2013-04-26 Thread Steve Molloy

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 RD
[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:rcm...@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.commailto:yo...@lucidworks.com wrote:
On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir 
rcm...@gmail.commailto:rcm...@gmail.com wrote:
 On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley 
 yo...@lucidworks.commailto: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-unsubscr...@lucene.apache.orgmailto:dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.orgmailto:dev-h...@lucene.apache.org
inline: image001.gif

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 smol...@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 RD

[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:rcm...@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 rcm...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

image001.gif

RE: [VOTE] Lucene Solr 4.3.0 RC3

2013-04-26 Thread Uwe Schindler

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: u...@thetaphi.de

 

From: Robert Muir [mailto:rcm...@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 smol...@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 RD

 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:rcm...@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 rcm...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

 

image001.gif

RE: [VOTE] Lucene Solr 4.3.0 RC3

2013-04-26 Thread Steve Molloy

That actually makes a lot of sense. ☺

Steve Molloy
Software Architect  |  Information Discovery  Analytics RD
[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:u...@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.dehttp://www.thetaphi.de/
eMail: u...@thetaphi.demailto:u...@thetaphi.de

From: Robert Muir [mailto:rcm...@gmail.com]
Sent: Friday, April 26, 2013 4:56 PM
To: dev@lucene.apache.orgmailto: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 
smol...@opentext.commailto:smol...@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 RD
[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:rcm...@gmail.commailto:rcm...@gmail.com]
Sent: April-26-13 10:16 AM
To: dev@lucene.apache.orgmailto: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.commailto:yo...@lucidworks.com wrote:
On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir 
rcm...@gmail.commailto:rcm...@gmail.com wrote:
 On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley 
 yo...@lucidworks.commailto: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-unsubscr...@lucene.apache.orgmailto:dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.orgmailto:dev-h...@lucene.apache.org

inline: image001.gif

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 u...@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: u...@thetaphi.de
  
 From: Robert Muir [mailto:rcm...@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 smol...@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 RD
 
 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:rcm...@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 rcm...@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-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [VOTE] Lucene Solr 4.3.0 RC3

2013-04-26 Thread Uwe Schindler

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: u...@thetaphi.de

 -Original Message-
 From: Mark Miller [mailto:markrmil...@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 u...@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: u...@thetaphi.de
 
  From: Robert Muir [mailto:rcm...@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 smol...@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 RD
 
  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:rcm...@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 rcm...@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-unsubscr...@lucene.apache.org For
  additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
 commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [VOTE] Lucene Solr 4.3.0 RC3

2013-04-26 Thread Uwe Schindler

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: u...@thetaphi.de

 

From: Dyer, James [mailto:james.d...@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:smol...@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 RD

 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:u...@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: u...@thetaphi.de

 

From: Robert Muir [mailto:rcm...@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 smol...@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 RD

 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:rcm...@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 rcm...@gmail.com wrote:
 On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley yo

Re: [VOTE] Lucene Solr 4.3.0 RC3

Patch up.

https://issues.apache.org/jira/browse/SOLR-4771

- Mark

On Apr 26, 2013, at 11:34 AM, Uwe Schindler u...@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: u...@thetaphi.de
  
 From: Dyer, James [mailto:james.d...@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:smol...@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 RD
 
 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:u...@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: u...@thetaphi.de
  
 From: Robert Muir [mailto:rcm...@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 smol...@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 RD
 
 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:rcm...@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 rcm...@gmail.com wrote:
  On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley yo...@lucidworks.com wrote:
  As to which

Re: [VOTE] Lucene Solr 4.3.0 RC3

On Wed, Apr 24, 2013 at 5:18 PM, Chris Hostetter
hossman_luc...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene Solr 4.3.0 RC3

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
 hossman_luc...@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-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene Solr 4.3.0 RC3

I committed a fix.

- Mark

On Apr 26, 2013, at 3:07 PM, Mark Miller markrmil...@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
 hossman_luc...@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-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene Solr 4.3.0 RC3