Remy Maucherat wrote:
> I don't understand why you think it's the same.
>
> For the ENC, you do something like:
> (new InitialContext()).lookup("java:/comp/env/maxExemptions");
>
> So you need the thread or CL binding to retrive the JNDI Context where
> maxExemptions is.
>
> For the config, you can for example give StandardContext a reference to
> the DirContext which contains the webapp configuration data. So no
> thread binding needed.
I think we're talking about different things.
Say I want to read WEB-INF/web.xml for application /examples.
Right now it seems what I have to do requires the use of the thread
or cl binding to locate the jndi context representing the war/files.
What I would like to do from inside tomcat is:
globalContext.lookup("host=localhost:8080, path=/examples,
file=/WEB-INF/web.xml")
( or some / based name: FILES:/localhost:8080/examples/WEB-INF/web.xml ).
I couldn't find any way to do that.
For the java:/comp/env - yes, the Context must be bound so that
the app can locate it using the InitialContext(). But it can
also be bound in the 'globalContext' - so that an admin app or
some listeners can see/alter the webapp bindings.
What I'm trying to say is that thread/classloader binding is
required in some cases, but it can be avoided in many other cases. And
in general there are a lot of 'tricky' things about it ( like if you
create a new thread and the binding no longer works ).
>> Sure. Just trying to get feedback and maybe get other people interested.
>> So far only 2 people seem interested in 'common-discovery'.
>
> I didn't look at it at all, sorry :-(
It's about using META-INF/services, and in general about supporting a
pattern where each .jar includes some resource with a fixed name
and you want to manipulate it.
Examples:
- locate Listeners/Valves/Interceptors that are installed, so that the
admin can display all available modules
- locate and automatically load any META-INF/mbeans.xml so that each module
can register his own description transparently
- possibly META-INF/ant.tasks ( or just
META-INF/services/org.apache.tools.ant.ProjectComponent ) - and have the
tasks automatically declared
- declare some interface for tomcat configurator ( like ant's ProjectHelper)
and have it loaded automatically. ( or different configurators that are
available, each getting a chance to configure )
- declare the JNDI providers or JDBC drivers so you don't need to
explicitely declare them
- support multiple parsers - and have a way to choose which one to use
( instead of 'select first' )
And so on.
Costin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
