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, yo
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>>And internals and 'priviledged' application will get access to the
>>>root of this tree, and look up anything configurable or runtime
>>>using the 'normal' API - with no tricks with classloader/thread binding.
>>
>>That's different from the
Costin Manolache wrote:
...
> Sure. Just trying to get feedback and maybe get other people interested.
> So far only 2 people seem interested in 'common-discovery'.
> I want to use it for an antlib 'experiment', but it would also help
> for tomcat. Something like ant's ProjectHelper hook to plug
Remy Maucherat wrote:
>> And internals and 'priviledged' application will get access to the
>> root of this tree, and look up anything configurable or runtime
>> using the 'normal' API - with no tricks with classloader/thread binding.
>
> That's different from the ENC, since here, you can give t
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>>The way I see it, we'll have 2 JNDI 'trees':
>>> - one for 'config data' ( the new one ).
>>> - one for 'runtime data' - including the VFS, various java:env, etc.
>>
>>Yes.
>>
>>I suppose you can take advantage of federation to make a giant
Remy Maucherat wrote:
>> The way I see it, we'll have 2 JNDI 'trees':
>> - one for 'config data' ( the new one ).
>> - one for 'runtime data' - including the VFS, various java:env, etc.
>
> Yes.
>
> I suppose you can take advantage of federation to make a giant big tree.
And internals and 'p
[EMAIL PROTECTED] wrote:
> On second tought, it would be excelent if you can map server.xml. The
> only issue I have is the naming hierarcy - but we can address that later.
Ok, I'll do it.
> One thing I hate in the current JNDI code is the binding on thread/class
> loader, etc. I understand wh
On second tought, it would be excelent if you can map server.xml. The
only issue I have is the naming hierarcy - but we can address that later.
One thing I hate in the current JNDI code is the binding on thread/class
loader, etc. I understand what it is supposed to do, but we shouldn't
have to
On Fri, 16 Aug 2002, Remy Maucherat wrote:
> I will bootstrap the new configuration code by writing a DOM based JNDI
> directory context to provide some compatibility with the current server.xml.
Great.
I am not very sure if we should spend too much time preserving the current
server.xml. If
I will bootstrap the new configuration code by writing a DOM based JNDI
directory context to provide some compatibility with the current server.xml.
I'll start experimenting with the JNDI naming conventions we'll be using
as I implement the context (obviously, that will happen in the test
prog
10 matches
Mail list logo
