multiple solr webapps (tentative)

[Yonik Seeley <ys...@gmail.com>]

I just checked in an implementation that allows for multiple Solr webapps.
It currently works for Tomcat (I tried 5.5.17), but I have no idea how
to get it to work with Jetty...

I used JNDI and Tomcat context fragments....
Just put a context fragment file under $CATALINA_HOME/conf/Catalina/localhost
for each solr webapp you want to run:

Yonik@spidey /cygdrive/f/opt/tomcat55/conf/Catalina/localhost
$ cat solr1.xml
<Context docBase="f:/solr.war" debug="0" crossContext="true" >
    <Environment name="solr/home" type="java.lang.String"
value="f:/solr1home" override="true" />
</Context>

Yonik@spidey /cygdrive/f/opt/tomcat55/conf/Catalina/localhost
$ cat solr2.xml
<Context docBase="f:/solr.war" debug="0" crossContext="true" >
  <Environment name="solr/home" type="java.lang.String"
value="f:/solr2home" override="true" />
</Context>

You don't put anything related to solr under webapps.
The paths to the two webapps will be http://host:port/solr1 and
http://host:port/solr2

If this seems fine with everyone, we can create a Wiki topic and let
people on solr-user know.

-Yonik

Re: multiple solr webapps (tentative)

[Yoav Shapira <yo...@apache.org>]

Hola,
There's a few different questions in here.  AFAIK:

- All servlet containers developed over the past ~5 years support at
least read-only JNDI, although it's only strictly required for
complete J2EE servers.

- There are three advantages to using JNDI over straight-up web.xml approaches:
  -- One is the ability to get the configuration data via JNDI using
command-line tools, JMX-driven consoles, and other stuff not specific
to a servlet container.  This allows for more managability and easier
unit-testing outside the container.

  -- The second advantage is easier dynamic changing of these
configuration files: typically to change web.xml you need to reload
the webapp, while changing JNDI does not require such a reload.

  -- Third, using JNDI allows you to specify default values and
override them without changing the WAR file that you distribute your
app in.

So yes, init-params would work, as would context-params, but you would
lose some of the above advantages.  How significant they are for Solr
is up for debate...

Finally:

> Is there an appserver that allows setting java:comp/env from outside
> the webapp but doesn't allow setting context-params?

Yes, in fact it's fairly normal for full J2EE servers to do this. In
general full J2EE servers (as opposed to servlet containers) allow the
admin to dynamically change JNDI resources, but are stricter with
stuff set by the developer like values in web.xml.  Recently they've
become a little less strict, but then again I haven't been using full
J2EE recently... ;)

Yoav


On 5/21/06, Yonik Seeley <ys...@gmail.com> wrote:
> On 5/21/06, Chris Hostetter <ho...@fucit.org> wrote:
> >
> > : I just wanted to make sure that JNDI was really the right way to go...
> > : Using those Context xml files in Catalina/localhost would also work
> > : with init-params AFAIK.
> >
> > Aren't init-params and context-params required to be specified in
> > the web.xml?
>
> I meant context-param, not init-param.  I brought it up because Tomcat
> also allows one to specify context-params outside the webapp.
> http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
> (search down for context-param).
>
> The upside to context-param is that it's a mandatory part of the servlet spec.
> Is there an advantage to the JNDI approach?
> Is there an appserver that allows setting java:comp/env from outside
> the webapp but doesn't allow setting context-params?
>
> -Yonik
>


-- 
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com

Re: multiple solr webapps (tentative)

[Yonik Seeley <ys...@gmail.com>]

On 5/21/06, Chris Hostetter <ho...@fucit.org> wrote:
>
> : I just wanted to make sure that JNDI was really the right way to go...
> : Using those Context xml files in Catalina/localhost would also work
> : with init-params AFAIK.
>
> Aren't init-params and context-params required to be specified in
> the web.xml?

I meant context-param, not init-param.  I brought it up because Tomcat
also allows one to specify context-params outside the webapp.
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
(search down for context-param).

The upside to context-param is that it's a mandatory part of the servlet spec.
Is there an advantage to the JNDI approach?
Is there an appserver that allows setting java:comp/env from outside
the webapp but doesn't allow setting context-params?

-Yonik

Re: multiple solr webapps (tentative)

[Chris Hostetter <ho...@fucit.org>]

: I just wanted to make sure that JNDI was really the right way to go...
: Using those Context xml files in Catalina/localhost would also work
: with init-params AFAIK.

Aren't init-params and context-params required to be specified in
the web.xml?

: Is r/o JINDI really required by the servlet spec?  I just looked at
: the 2.4 servlet spec, and it's not clear to me.  See "encouraged, but
: not required" near the bottom.

My reading of that (and the other refrences for env-entry in the PDF of
the spec i just searched) is that supporting env-entry is only required
for the J2EE 1.4 spec ... not servlet 2.4.

But frankly, i don't know if that's that big a deal .. we can still say
SOlr works with any servlet 2.4 container -- there are just some features
that require extended servlet container features ... not that much worse
then index snapshooting requiring hard links, and replication requiring
rsync.



-Hoss

Re: multiple solr webapps (tentative)

[Yonik Seeley <ys...@gmail.com>]

I just wanted to make sure that JNDI was really the right way to go...
Using those Context xml files in Catalina/localhost would also work
with init-params AFAIK.

Is r/o JINDI really required by the servlet spec?  I just looked at
the 2.4 servlet spec, and it's not clear to me.  See "encouraged, but
not required" near the bottom.


SRV.9.11 Web Application Environment
The JavaTM 2 Platform, Enterprise Edition defines a naming environment
that allows
applications to easily access resources and external information
without explicit
knowledge of how the external information is named or organized.
As servlets are an integral component type of J2EE technology, provision has
been made in the Web application deployment descriptor for specifying
information allowing a servlet to obtain references to resources and enterprise
beans. The deployment elements that contain this information are:
• env-entry
• ejb-ref
• ejb-local-ref
• resource-ref
• resource-env-ref
The developer uses these elements to describe certain objects that the Web
application requires to be registered in the JNDI namespace in the Web container
at runtime.
The requirements of the J2EE environment with regard to setting up the
environment are described in Chapter J2EE.5 of the JavaTM 2 Platform, Enterprise
Edition version 1.4 specification1. Servlet containers that are not
part of a J2EE
technology-compliant implementation are encouraged, but not required, to
implement the application environment functionality described in the J2EE
specification. If they do not implement the facilities required to support this
environment, upon deploying an application that relies on them, the container
should provide a warning.


-Yonik

Re: multiple solr webapps (tentative)

[Yoav Shapira <yo...@apache.org>]

+1 as well, looks reasonable.

Yoav

On 5/21/06, Chris Hostetter <ho...@fucit.org> wrote:
>
> I haven't had a chance to try it out, but the diff makes sense.
>
> : If this seems fine with everyone, we can create a Wiki topic and let
> : people on solr-user know.
>
> +1
>
>
>
> -Hoss
>
>


-- 
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com

Re: multiple solr webapps (tentative)

[Chris Hostetter <ho...@fucit.org>]

I haven't had a chance to try it out, but the diff makes sense.

: If this seems fine with everyone, we can create a Wiki topic and let
: people on solr-user know.

+1



-Hoss