This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 17934 - Naming service over content of system file system
Summary: Naming service over content of system file system
Alias: None
Product: platform
Classification: Unclassified
Component: Lookup (show other bugs)
Version: 3.x
Hardware: PC Linux
: P1 blocker (vote)
Assignee: Petr Hrebejk
: 21275 (view as bug list)
Depends on: 19903 19904 19905
Blocks: 18177 20838 26921
  Show dependency tree
Reported: 2001-11-21 17:23 UTC by Jaroslav Tulach
Modified: 2009-10-23 22:51 UTC (History)
6 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2001-11-21 17:23:57 UTC
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.
Comment 1 Jaroslav Tulach 2001-11-21 17:33:20 UTC
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.
Comment 2 Jaroslav Tulach 2001-11-27 11:11:05 UTC
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.
Comment 3 Jaroslav Tulach 2002-01-11 12:52:15 UTC
It is necessary to update the Context to EventContext so it is
possible to listen on changes in the context.
Comment 4 Jesse Glick 2002-01-28 14:30:08 UTC
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.
Comment 5 Jaroslav Tulach 2002-01-29 15:15:58 UTC
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
notification extension.
Comment 6 Jaroslav Tulach 2002-03-11 16:20:38 UTC
*** Issue 21275 has been marked as a duplicate of this issue. ***
Comment 7 Jaroslav Tulach 2002-03-11 16:21:50 UTC
A page with description of the reasons why it seems we need JNDI has
been added to
Comment 8 Jaroslav Tulach 2002-07-26 18:15:17 UTC
This issue blocks Looks APIs. The priority should be P1, some one
please change it.
Comment 9 Petr Hrebejk 2003-07-29 15:13:10 UTC
Should be fixed by the RegistryAPI