Solr
  1. Solr
  2. SOLR-1448

Addition of weblogic.xml required for solr to run under weblogic 10.3

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.4
    • Component/s: web gui
    • Labels:
      None
    • Environment:

      Weblogic 10.3

      Description

      Weblogic appears to have filters enabled even on FORWARD, which is listed as something that will not function properly in the Solr documentation. As a result, the administrative application generates a StackOverflow when accessed.

      This can be resolved by adding the attached weblogic.xml file to solr. No other changes are required.

      <?xml version='1.0' encoding='UTF-8'?>
      <weblogic-web-app
      xmlns="http://www.bea.com/ns/weblogic/90"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">

      <container-descriptor>
      <filter-dispatched-requests-enabled>false</filter-dispatched-requests-enabled>
      </container-descriptor>

      </weblogic-web-app>

      1. weblogic.xml
        0.4 kB
        Ilan Rabinovitch

        Activity

        Hide
        Ilan Rabinovitch added a comment -

        Please this file in WEB-INF/weblogic.xml

        Show
        Ilan Rabinovitch added a comment - Please this file in WEB-INF/weblogic.xml
        Hide
        Noble Paul added a comment -

        does this same file work with all versions of weblogic. we have no means of verifying this

        Show
        Noble Paul added a comment - does this same file work with all versions of weblogic. we have no means of verifying this
        Hide
        Ilan Rabinovitch added a comment -

        It was required under both weblogic 10.1 and 10.3. We have not use previous versions of weblogic with solr

        Show
        Ilan Rabinovitch added a comment - It was required under both weblogic 10.1 and 10.3. We have not use previous versions of weblogic with solr
        Hide
        Grant Ingersoll added a comment -

        I don't see a need to put specific files for specific containers into Solr. See http://wiki.apache.org/solr/SolrWeblogic.

        Show
        Grant Ingersoll added a comment - I don't see a need to put specific files for specific containers into Solr. See http://wiki.apache.org/solr/SolrWeblogic .
        Hide
        Hoss Man added a comment -

        Grant: I don't understand your objection to this addition. It makes solr work in weblogic by default (currently it will only work if people manually hack the war) and it doesn't have any impact on any other servlet containers.

        If we're going to do things like SOLR-1091 to work around odd behavior in specific containers, why wouldn't we do this as well?

        Show
        Hoss Man added a comment - Grant: I don't understand your objection to this addition. It makes solr work in weblogic by default (currently it will only work if people manually hack the war) and it doesn't have any impact on any other servlet containers. If we're going to do things like SOLR-1091 to work around odd behavior in specific containers, why wouldn't we do this as well?
        Hide
        Hoss Man added a comment -

        reopening to get back on radar for discussion (see my previous comment)

        Show
        Hoss Man added a comment - reopening to get back on radar for discussion (see my previous comment)
        Hide
        Mark Miller added a comment -

        Missed this discussion after seeing this issue come up - thought it was a good idea myself.

        +1 - its a .4KB file that doesn't hurt or affect anything - and yet it makes Solr properly work out of the box with Weblogic - +1 all the way.

        Show
        Mark Miller added a comment - Missed this discussion after seeing this issue come up - thought it was a good idea myself. +1 - its a .4KB file that doesn't hurt or affect anything - and yet it makes Solr properly work out of the box with Weblogic - +1 all the way.
        Hide
        Grant Ingersoll added a comment -

        Are we going to be responsible for all the containers out there? How many of us have access to Web logic to test this? What versions of WebLogic are we going to support? What happens when WebLogic breaks it because a newer version changes it? Are we going to package different wars for different containers? How about other containers? It's a slippery slope.

        Show
        Grant Ingersoll added a comment - Are we going to be responsible for all the containers out there? How many of us have access to Web logic to test this? What versions of WebLogic are we going to support? What happens when WebLogic breaks it because a newer version changes it? Are we going to package different wars for different containers? How about other containers? It's a slippery slope.
        Hide
        Mark Miller added a comment -

        Are we going to be responsible for all the containers out there?

        I'd think we would take it on a case by case basis. We should generally work with a standards compliant container. We can see from the list that a handful of users are using weblogic - we can also see that there is a problem, and that there is a successful fix. I'm not seeing any comments about other containers that don't work (though perhaps I am missing them). I've seen the weblogic stuff enough to know about it without looking it up. In any case, I'd go case by case given the facts.

        How many of us have access to Web logic to test this?

        Its a point, but we have this issue all the time - hence all of the, can user please test this in their environ and report back. Thats how Hoss wrangled this one out as well I believe. And more than one user has confirmed.

        What versions of WebLogic are we going to support?

        The ones that users alert us don't work and have a simple fix for? We are not jumping hoops here - this is one specific setting that appears to be incompatible with the Solr admin UI. If future versions require major other changes, we would have to reassess. As it is, I think this has already been reported to make Solr admin work with 8,9, and 10. Thats a free win to me. Its a binary setting thats being set in this patch - thats it - at worse they will change it to default as we want. Which they actually did in weblogic 9 - but only if the web.xml is defined as 2.4 - and ours is 2.3 if I remember right. In any case, if a user is using a new version and reports issues, I'd think we would deal with it then based on the facts. This isn't a promise to work perfect with weblogic forever more any more than I promise to introduce no more bugs.

        Are we going to package different wars for different containers?

        No - this is just talking about including a .4kb file that doesn't affect different containers. No one is talking about making different wars. -1 to making different wars.

        How about other containers?

        Case by case as it should be. Hopefully most of them just work as this is supposed to be standards driven. When we have little issues like this, I'd think we go case by case.

        It's a slippery slope.

        I don't think this little patch makes things any more slippery than they are myself.

        Show
        Mark Miller added a comment - Are we going to be responsible for all the containers out there? I'd think we would take it on a case by case basis. We should generally work with a standards compliant container. We can see from the list that a handful of users are using weblogic - we can also see that there is a problem, and that there is a successful fix. I'm not seeing any comments about other containers that don't work (though perhaps I am missing them). I've seen the weblogic stuff enough to know about it without looking it up. In any case, I'd go case by case given the facts. How many of us have access to Web logic to test this? Its a point, but we have this issue all the time - hence all of the, can user please test this in their environ and report back. Thats how Hoss wrangled this one out as well I believe. And more than one user has confirmed. What versions of WebLogic are we going to support? The ones that users alert us don't work and have a simple fix for? We are not jumping hoops here - this is one specific setting that appears to be incompatible with the Solr admin UI. If future versions require major other changes, we would have to reassess. As it is, I think this has already been reported to make Solr admin work with 8,9, and 10. Thats a free win to me. Its a binary setting thats being set in this patch - thats it - at worse they will change it to default as we want. Which they actually did in weblogic 9 - but only if the web.xml is defined as 2.4 - and ours is 2.3 if I remember right. In any case, if a user is using a new version and reports issues, I'd think we would deal with it then based on the facts. This isn't a promise to work perfect with weblogic forever more any more than I promise to introduce no more bugs. Are we going to package different wars for different containers? No - this is just talking about including a .4kb file that doesn't affect different containers. No one is talking about making different wars. -1 to making different wars. How about other containers? Case by case as it should be. Hopefully most of them just work as this is supposed to be standards driven. When we have little issues like this, I'd think we go case by case. It's a slippery slope. I don't think this little patch makes things any more slippery than they are myself.
        Hide
        Erik Hatcher added a comment -

        From the peanut gallery: +1 to including this fix and dealing with things on case-by-case in the future.

        It is an ugly issue though.. so much for deployment descriptors. J2EE is busted in this respect, these types of things were meant to be controlled during deployment. Weblogic: -1 for needing this. Tomcat works, and it's the reference implementation.

        In the past I've had to deal with these sorts of things with Weblogic, WebSphere, and Resin (thank god we're not doing EJB!) - so I understand the pain point first hand and am ok with us including this Weblogic specific file in this case.

        We'll of course revisit when/if other containers have issues.

        Show
        Erik Hatcher added a comment - From the peanut gallery: +1 to including this fix and dealing with things on case-by-case in the future. It is an ugly issue though.. so much for deployment descriptors. J2EE is busted in this respect, these types of things were meant to be controlled during deployment. Weblogic: -1 for needing this. Tomcat works, and it's the reference implementation. In the past I've had to deal with these sorts of things with Weblogic, WebSphere, and Resin (thank god we're not doing EJB!) - so I understand the pain point first hand and am ok with us including this Weblogic specific file in this case. We'll of course revisit when/if other containers have issues.
        Hide
        Grant Ingersoll added a comment -

        It's a can of worms I'd rather not open.

        I won't -1 it, but I'm pretty strongly -0, if that means anything, or perhaps -0.9 for all the reasons I cited and Erik's as well. My biggest reason is simply that I don't believe any committers here have access to Weblogic, so if it ever breaks, we don't have the means to manage it, even if it is simple.

        Show
        Grant Ingersoll added a comment - It's a can of worms I'd rather not open. I won't -1 it, but I'm pretty strongly -0, if that means anything, or perhaps -0.9 for all the reasons I cited and Erik's as well. My biggest reason is simply that I don't believe any committers here have access to Weblogic, so if it ever breaks, we don't have the means to manage it, even if it is simple.
        Hide
        Mark Miller added a comment -

        and Erik's as well

        Whats Erik's reason? He's +1 for including.

        My biggest reason is simply that I don't believe any committers here have access to Weblogic,

        Well they do if they want to download it. I don't really think that matters for this change myself, and I don't recommend the download either. I'd sooner shoot myself in the foot after downloading Oracle's db. Free for dev, pay for production. Its an over worry for flipping this setting though.

        Show
        Mark Miller added a comment - and Erik's as well Whats Erik's reason? He's +1 for including. My biggest reason is simply that I don't believe any committers here have access to Weblogic, Well they do if they want to download it. I don't really think that matters for this change myself, and I don't recommend the download either. I'd sooner shoot myself in the foot after downloading Oracle's db. Free for dev, pay for production. Its an over worry for flipping this setting though.
        Hide
        Grant Ingersoll added a comment -

        He's +1, but if you my interpretation is that it is solely for the fact that this particular case isn't too obnoxious. In this case, I don't see why we should have to do things just b/c Weblogic has a crappy design.

        Like I said, though, I won't -1 it. If y'all want to maintain it and are prepared to rework this in a year for the new weblogic go for it. However, the minute someone proposes web logic version 2 descriptor (when it comes out), I'm going to -1 it and this one.

        Show
        Grant Ingersoll added a comment - He's +1, but if you my interpretation is that it is solely for the fact that this particular case isn't too obnoxious. In this case, I don't see why we should have to do things just b/c Weblogic has a crappy design. Like I said, though, I won't -1 it. If y'all want to maintain it and are prepared to rework this in a year for the new weblogic go for it. However, the minute someone proposes web logic version 2 descriptor (when it comes out), I'm going to -1 it and this one.
        Hide
        Mark Miller added a comment -

        solely for the fact that this particular case isn't too obnoxious.

        Thats why any of us are +1 from what I can read.

        In this case, I don't see why we should have to do things just b/c Weblogic has a crappy design.

        We don't have to. But since it helps and it doesn't hurt, it seems to make sense.

        If y'all want to maintain it and are prepared to rework this in a year for the new weblogic go for it.

        Adding this file is not a contract to support weblogic. And the the setting being changed (the only setting) is one that this isn't even a valid concern.

        However, the minute someone proposes web logic version 2 descriptor (when it comes out)

        Case by case. Like I said - with weblogic 9+, we won't even need this when Solr's web.xml moves to 2.4.

        Show
        Mark Miller added a comment - solely for the fact that this particular case isn't too obnoxious. Thats why any of us are +1 from what I can read. In this case, I don't see why we should have to do things just b/c Weblogic has a crappy design. We don't have to. But since it helps and it doesn't hurt, it seems to make sense. If y'all want to maintain it and are prepared to rework this in a year for the new weblogic go for it. Adding this file is not a contract to support weblogic. And the the setting being changed (the only setting) is one that this isn't even a valid concern. However, the minute someone proposes web logic version 2 descriptor (when it comes out) Case by case. Like I said - with weblogic 9+, we won't even need this when Solr's web.xml moves to 2.4.
        Hide
        Ilan Rabinovitch added a comment -

        Have we reached a consensus on this? I believe Mark is correct regarding the file becoming obsolete once solr moves web its web.xml to 2.4. However, since that wont occur with Solr 1.4 I dont see any reason why this would cause problems in the upcoming release.

        Show
        Ilan Rabinovitch added a comment - Have we reached a consensus on this? I believe Mark is correct regarding the file becoming obsolete once solr moves web its web.xml to 2.4. However, since that wont occur with Solr 1.4 I dont see any reason why this would cause problems in the upcoming release.
        Hide
        Yonik Seeley added a comment -

        Thanks Ilan, I just committed this.

        Show
        Yonik Seeley added a comment - Thanks Ilan, I just committed this.
        Hide
        Grant Ingersoll added a comment -

        Bulk close for Solr 1.4

        Show
        Grant Ingersoll added a comment - Bulk close for Solr 1.4

          People

          • Assignee:
            Yonik Seeley
            Reporter:
            Ilan Rabinovitch
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development