Hello.
Based on some of Stephen's comments, I've worked out the following example
schema for context declaration. Any "source" attributes would use the
SourceResolver to return values. I think this is a more dynamic way to
handle things, but I'm not sure how I feel about adding the dependency.
Anyway, here's a few ways it could be used:
<context>
<!-- simplest use case, value is mapped to the key -->
<entry key="name" value="value"/>
<!-- use of a runtime generated class -->
<entry key="name" source="class://org.my.SpecialClass">
<constructor source="class://org.my.DualArgContructor">
<param class="java.lang.String">String</param>
<param class="java.io.File">../</param>
</constructor>
</entry>
<!-- various other lookups using the source resolver -->
<entry key="name" source="jndi://my_jndi_name"/>
<entry key="name" source="urn:avalon:classloader"/>
<entry key="name" source="avalon://some-service-name"/>
<entry key="name" source="servlet://some-context-name"/>
<entry key="name" source="jvm://operating-system"/>
<!-- use of a Context Extension Handler of some sort -->
<entry key="name">
<extension source="class://org.my.ContextExtensionHandler"/>
</entry>
<!-- I like the idea of regex matching for names, but this
probably belongs in a context extension declaration
in the kernel space -->
<entry key="[regex]">
<extension source="avalon://extension-handler-service"/>
</entry>
</context>
Just some ideas to kick around. The source resolver would be nice because
then if you want to lookup several values from a remote JNDI location, you
don't need to reinitialize the InitialContext for each lookup. However, I'm
not sure how well using SourceResolver in the "meta" level of things would
work. Any thoughts?
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
