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:
--
On 5/21/06, Chris Hostetter <[EMAIL PROTECTED]> 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 w
: 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 sp
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,
+1 as well, looks reasonable.
Yoav
On 5/21/06, Chris Hostetter <[EMAIL PROTECTED]> 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
Nimale
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
Yup, env-entry and resource-ref should both work. That's what I meant
by a read-only JNDI impl, sorry if I was unclear...
Yoav
On 4/19/06, Bill Au <[EMAIL PROTECTED]> wrote:
> It looks like we can use , which is part of the servlet specs:
>
>
> solr/home
> java.lang.String
> /var/opt/solr
It looks like we can use , which is part of the servlet specs:
solr/home
java.lang.String
/var/opt/solr/product
The configuration will be the same for all containers.
Bill
On 4/19/06, Yoav Shapira <[EMAIL PROTECTED]> wrote:
>
> I'd be shocked if Jetty (regular / free) doesn't support re
I'd be shocked if Jetty (regular / free) doesn't support reading JNDI,
as I think that's a servlet spec requirement. Some containers, like
Tomcat and apparently Jetty, make a full read/write JNDI
implementation not part of the core container.
Yoav
On 4/19/06, Bill Au <[EMAIL PROTECTED]> wrote:
>
Using JNDI seems like a good approach.
We will need to add JNDI support as a requirement of the appserver for
running Solr.
Jetty doesn't support JNDI but JettyPlus does.
Bill
On 4/18/06, Yoav Shapira <[EMAIL PROTECTED]> wrote:
>
> Hola,
>
>
> > Do I have that correct?
>
> Yeah.
>
> --
> Yoav S
Hola,
> Do I have that correct?
Yeah.
--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com
: Another approach to consider, then, is using the server's JNDI
: resources. The code in the WAR would be the same, looking up the
: configuration file URL (or any other JNDI resource) using the
: java:comp/env space (which is different for every webapp, and portable
: across all J2EE servers/se
Hola,
> request, I can find out that someone used the solr1 path to get to me
> (but that's to late for config type stuff that needs to happen in
> init()).
That but... clause is very important. From what I understand, the
Servlet EG discussed this long and hard, many times, over many months,
be
On 4/18/06, Yoav Shapira <[EMAIL PROTECTED]> wrote:
> There's no portable way of doing that, quite on purpose: the webapp is
> supposed to run the same independent of its server admin-dependent
> deployment details
Yeah, but it's not the same now; if I rename my webapp to solr1.war,
I'll be able t
Yeah, it should. IMHO that call was only added as a kowtow to people
demanding an easy hack approach -- and there's something to be said
for that, if many people demand it. But it was still added
half-heartedly, as it requires a request, i.e. you can't use it an
initialization time before any req
But shouldn't the return value of HttpServletRequest.getContextPath()
be the same independing of packaging (WAR or no WAR)?
Bill
On 4/18/06, Yoav Shapira <[EMAIL PROTECTED]> wrote:
>
> Hola,
>
> No, don't use getServletContextName(). Besides being optional, it
> doesn't necessarily related to a
Hola,
> But the goal was to have the exact same solr WAR, just copied to
> different names... so we need some way to find out the in
> .war
There's no portable way of doing that, quite on purpose: the webapp is
supposed to run the same independent of its server admin-dependent
deployment details
On 4/18/06, Yoav Shapira <[EMAIL PROTECTED]> wrote:
> There are a couple of
> alternatives, one using the classpath and one using the
> ServletContext#getResource approach.
But the goal was to have the exact same solr WAR, just copied to
different names... so we need some way to find out the in
.
Hola,
No, don't use getServletContextName(). Besides being optional, it
doesn't necessarily related to a path on the disk. For that matter,
don't use the disk path approach anyhow, as things get quirky /
fragile for users running packed WARs. There are a couple of
alternatives, one using the cl
: Unfortunately not the javadoc says it comes from the web.xml
:
: java.lang.String getServletContextName()
: Returns the name of this web application corresponding to
: this ServletContext as specified in the deployment descriptor for this
: web application by the display-name
On 4/18/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
> (or does ServletContext.getServletContextName() not do what I think i
> remember it doing)
Unfortunately not the javadoc says it comes from the web.xml
java.lang.String getServletContextName()
Returns the name of this w
: I've been looking into how to have multiple solr webapps, and have
: them default to looking into different spots for config (and looking
: at a different property to override that).
:
: Unfortunately, it doesn't look like there is a way to do this from the
: servlet API.
Can't we just use Servl
22 matches
Mail list logo
