A lot of APIs is going to use content of system file system to let other modules
to register services and than use them. It is silly for such API to depend on
loader's API and/or FolderInstance. An abstraction is needed.<p/>
Currently it is possible to do such registration in /Services folder and access
such objects via Lookup. But the problem is that for a huge number of services
there is a natural naming convention that could be used to find out the correct
The goal of this task is to enhance Lookup, implement JNDI provider or use some
other technique that will allow various APIs to get functionality of
FolderInstance without actually touching loaders API.
Actions API (issue 17597), resolution of Environment.Provider for xml
based on DTD name, Custom Format of IDO (issue 17924) are likely to
depend on this feature.
First read/only version has been created in branch lookup_api_2001
modified files are just in module core (org.netbeans.core.lookup
cvs co -r lookup_api_2001 -f core
will give you the correct sources.
It is necessary to update the Context to EventContext so it is
possible to listen on changes in the context.
I would like to suggest another candidate for using this:
NbfsStreamHandlerFactory should deprecate the register and deregister
methods, and look up handlers based on protocol name.
And don't forget finding a TopComponent from a *.wstcref file! The
current semantics in Windows/Components/ works but could be made more
general, I think.
Changing this into a cover issue for three different levels of
implementation: issue 19903 covers the plain read only implementation,
issue 19904 the writeable implementation and issue 19905 the event
*** Issue 21275 has been marked as a duplicate of this issue. ***
A page with description of the reasons why it seems we need JNDI has
been added to
This issue blocks Looks APIs. The priority should be P1, some one
please change it.
Should be fixed by the RegistryAPI