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.
The current API and implementation of Lookup is lacking in various areas. Yarda and others think that JNDI could help significantly. JNDI is not meant to replace Lookup but rather complements it in useful ways.
Heated discussion is running on nbdev right now. I attach the more informative message From: Svatopluk Dedic <Svatopluk.Dedic@sun.com> Subject: Re: [nbdev] Small core & JNDI To: <nbdev@netbeans.org> Date: Tue, 5 Mar 2002 14:55:02 +0100 (CET) Reply-To: nbdev@netbeans.org On 5 Mar 2002, Trung Duc Tran wrote: > the fundamental question I like to ask is "Should we use JNDI or not?". > What's the reason? What problem are we trying to solve? Why JNDI? > Usage scenarios? > 1) Ability to name an instance & retrieve the instance in another IDE session. This is achieved by storing Lookup.Item.getId(), but it's not defined whether the returned ID is a path through the Lookup contents, identifier of the returned instance or what. Besides that, Naming interfaces are the *standard* way how to name objects and retrieve them later. 2) Separate identification and communication protocol Currently inteface's type is both a protocol between the client and the service being looked up, but also the service's identifier. What if there are more service, which serve the interface ? Has the client always sort through them, using the service-private protocol to locate and identify the "correct" one ? If the client could use a different name (as with Naming), it could get the correct service using a well-known (JNDI) mechanism. 3) Performance Since Name gives a path through the (possibly) compound namespace, navigation to the identified service is straightforward and much faster than wide search for anything matching the attributes (the lookup class and its supertypes) in a flat namespace 4) Binding attributes. Since DirectoryContext from JDNI supports attributed bindings, you can take further our InstanceCookie.Of, allowing clients to search for something that match their needs based on attributes without needing to materialize the service. This is currently hacked into InstanceCookie.Of as a special case. If you allow different naming convention than the implementation type, generalized attributes is the correct way. 5) Well-defined registration. An implementation of a serivce can't choose how it gets registered in Lookup: it is registered as any of its supertypes. It's really not possible to register a subclass of JavaCompilerType specialzed for a particular task, because anyone looking for a (generic) JavaCompilerType will find it. With JNDI, one can bind the service to several names and may choose what those names should be. In other words, although I need to derive the service from JavaCompilerType because of implementation reasons, I am not obliged to publish it as a generic java compiler type. 6) Scalability Consider (3) in a system with several dozens of modules communicating with each other. A module has to publish its services somehow so others can locate them. If the registry is flat, the performance will degrade more than linearly with number of registered modules. Look at Windows registry, under KHEY_CLASSES_ROOT - this is what Lookup is about. On the contrary, look in HKEY_CURRENT_USER/Software: this is what JNDI is about. > What I would like to avoid at all cost is the bitter lesson learned from > the original Lookup, which was supposed to solve all problems of the > world but haven't met its promises. The original Lookup code is not > that old and we are already trying to switch to a new interface (JNDI). > "Which Lookup do you want to use today?" > As you said - Lookup was said to solve all problems and use cases. It didn't. So either we should extend Lookup to solve them, work around them - or use a standard interface which offers the solution. Lookup is good for undirected queries of one style "just give me something that understands protocol org.netbeans.Foo". Try to persuade me that we don't need other types of queries. > Don't forget we are only 9 weeks away from NB 3.4 freeze, and the bug > count is going up (among other things) > Yes, I know. But on the other hand, I would like to have some *usable* registration tool which performs well and scales well: isn't version 3.4 mature enough to have one ? I'm not accepting this argument given that core team is supposed to build a platform (or the IDE's core), which *does* scale. -Svata
Another message from Petr Nejedly From: Petr Nejedly <petr.nejedly@Sun.COM> Subject: Re: [nbdev] Small core & JNDI To: nbdev@netbeans.org Date: Tue, 05 Mar 2002 12:05:27 +0100 Reply-To: nbdev@netbeans.org [...] I'll try to reply both David and Trung at once: Why I always see the "One Size Fits All" paradigm here? Lookup is Lookup and Naming is Naming. The original discussion died without conclusion IIRC, but there was a consensus that Naming is better for singletons than the Lookup. We did not come to a consensus regarding services. What problem is JDNI trying to solve? That is a question. One problem of the Lookup is that it needs to preprocess the metadata which is costly. (We're replaced initialization of data with initialization of metadata) We're thinking about persisting the content of the lookup, but this is more a workaround than a solution (OK, I know it worked for TeX 20 years ago, so it may work for us as well). The other problem is the current size of the FolderLookup. Just unhide the SFS and look at the Services folder. Naming can help us reduce even the amount of the metadata initialized. I asked a question: Why there is a need to have those (mostly) module private singletons (Settings), which can be easily moved to naming, placed in the Lookup? Because the system needs to know about them because of visualization in Options dialog. Maybe there is another solution for this, like remove the options from the Services folder and make the SystemOption to look not only to Lookup but also to the place where we'll move Options to (other than the Naming). My idea is following: Lookup probably has its place in the general intermodule communication. But for well-estabilished channels we could use something more effective, as the Lookup (as defined and implemented by the FolderLookup) is not very scallable and probably won't be without clever* caching. *) clever = more than serialization of the content Paralel: In the NB2.x days, every module was unpacking his templates from a jar to SFS during the instalation and was manually creating the menu items, toolbars and so on. We've replaced it with layers, i.e. we're holding the initialized state from the beginning, modules don't have to do it explicitely in their ModuleInstall. I see some similarity here with Lookup vs. Naming: Lookup - preparse the content of settings files to have the information needed for subsequent queries. Naming - Prepare nothing, queries will lead us to proper place. I'm not pushing this issue now as it would mean some design work and a lot of changes in modules to have real impact and we have only those 9 weeks. And I have not yet convinced Yarda to admit the Lookup was not the best possible thing (although quite qood) :-) I only expressed my feeling that we should not have separate module for every other class.
Yarda in his own words From: Jaroslav Tulach <yarda.tulach@czech.sun.com> Subject: [nbdev] Why JNDI + Lookup is not dead was: [nbdev] Small core & JNDI To: nbdev@netbeans.org Date: Wed, 06 Mar 2002 16:51:00 +0100 Reply-To: nbdev@netbeans.org Organization: Sun Microsystems, Inc. Trung Duc Tran wrote: > the fundamental question I like to ask is "Should we use JNDI or not?". That is the question. Answers may vary... > What's the reason? ...but we need a solution to kill code like this http://www.netbeans.org/source/browse/core/src/org/netbeans/core/windows/PersistenceManager.java.diff?r1=1.17&r2=1.18 (line 408) and this http://www.netbeans.org/source/browse/core/src/org/netbeans/core/xml/FileEntityResolver.java.diff?r1=1.8&r2=1.9 (line 242, findObject) and the bunch of similar code that would have to be introduced in openidex/commands and openidex/looks modules if they do not use naming. > What problem are we trying to solve? The ones described above plus the need to deprecated FolderInstance (which has grown and is too complicated to change anything there) and replace it with a cleaner API. I'll try to prepare webpage summary of the problems. > What I would like to avoid at all cost is the bitter lesson learned from > the original Lookup, which was supposed to solve all problems of the > world but haven't met its promises. Trung, maybe you should be a bit appreciative - the lookup was not supposed to solve all problems and it delivers exactly what it promised - service oriented communication between modules. > The original Lookup code is not > that old and we are already trying to switch to a new interface (JNDI). This is a misunderstanding. We are not going to stop using org.openide.util.Lookup. We are going to stop using FolderInstance and the code in PersistenceManager and FileEntityResolver. Comparing this to lookup is like comparing oranges to bananas. > Don't forget we are only 9 weeks away from NB 3.4 freeze, and the bug > count is going up (among other things) Another reason to introduce common framework and vanish the uglyness of above mentioned classes. y.
And Jesse's From: Jesse Glick <jesse.glick@sun.com> Subject: Re: [nbdev] Why JNDI + Lookup is not dead was: [nbdev] Small core & JNDI Newsgroups: netbeans.nbdev To: nbdev@netbeans.org Date: Wed, 06 Mar 2002 17:44:14 +0200 Reply-To: nbdev@netbeans.org Organization: Sun Microsystems / NetBeans > Trung Duc Tran wrote: >>What's the reason? Jaroslav Tulach wrote: > ....but we need a solution to kill code like this > http://www.netbeans.org/source/browse/core/src/org/netbeans/core/windows/PersistenceManager.java.diff?r1=1.17&r2=1.18 > (line 408) and this > http://www.netbeans.org/source/browse/core/src/org/netbeans/core/xml/FileEntityResolver.java.diff?r1=1.8&r2=1.9 > (line 242, findObject) > and the bunch of similar code that would have to be introduced in > openidex/commands and openidex/looks modules if they do not use naming. FWIW I agree that adding JNDI support is not gratuitous but solves present needs: - The window system needs to find top components according to a particular name. There is working but rather ugly (and hard-to-extend) code to do this now. Using JNDI would centralize the process of finding the instances and make the winsys code simpler. - There are other places where we have a clear need to find an object or collection of them according to a well-defined name/path. XML environment processors are one example. Looks (however these work out) will need the same. I would like to do something like this to find URL stream handlers, so as to replace static registration calls. - Lookup and JNDI overlap a bit, but serve different purposes and should be expected to coexist. - JNDI is included in the Java platform and is the standard and recognized way to find objects by their name. Many programmers will already be familiar with its basic usage, so it should not make module writing conceptually less intuitive. I don't see any pressing need to replace service lookup (e.g. compiler types) with JNDI searches, since I think it is tolerably optimized already (and an effective caching scheme is known); I think this should be considered out-of-scope for 3.4, to be discussed as time permits. Looking forward to a summary of why you think FolderInstance needs to be deprecated, and what the replacement would look like. -Jesse
I have recorded this discussion at http://openide.netbeans.org/proposals/settings/access.html *** This issue has been marked as a duplicate of 17934 ***
change lookup/core -> lookup/openide