Bug 26721

Summary: Store promitive values efficiently in JNDI Context
Product: contrib Reporter: Vitezslav Stejskal <vstejskal>
Component: NamingAssignee: issues <issues.netbeans.org>
Status: RESOLVED WONTFIX QA Contact: issues <issues.netbeans.org>
Priority: P1 CC: issues, jtulach, sdedic
Version: 3.x   
Target Milestone: 3.x   
Hardware: PC   
OS: Windows ME/2000   
Whiteboard:
Issue Type: TASK Exception Report:

Description Vitezslav Stejskal 2002-08-22 19:52:57 UTC
Original ideas from Svata:

(5) Storing primitive properties
  Currently they are serialized, each property in its own .settings file,
  right ? I mentioned two possible solutions to Vita and would like to
  open a discussion about their usefullness:

  a) Yet Another Proxy Context
  The private settings container is currently it's directly taken from
  Core's JNDI over FileSystem implementation.
  A solution would be to create a proxying Context implementation similar
  to MultiFileSystem -- that would decide where to bind() the particular
  object. Then a Context over a Properties bean could be created suitable
  for only some types, throwing NamingExceptions for others.
  If the object is one of "known" types (e.g. primitive, String, arrays of
  these), the proxy would delegate to the "PropertiesContext"
  implementation, if not, it would delegate to the JNDI over FS impl
  obtained from Core.
  Of course, the new proxying context impl could be merged with the
  "PropertiesContext" impl, if such impl won't be useful elsewhere

  b) Yet Another SubContext.
  Another possibility is to introduce a special call that would create a
  named "subcontext" implemented over a Properties object stored in a
  regular JNDI over filesystem context (as proposed above). This time it
  would be settings client's job to ask for such settings (sub)container.

  I favour (b) over (a) for the sake of project filesystem's readability
  -- different API clients will use different subcontext (XML properties
  files) to store their settings, so they will be separated in the
  storage. (a) will save the work for clients, but will merge all
  primitive things at once place, and the clients will STILL have to use
  unique prefixes so the setting names do not clash (except that the
  unique prefix will be part of simple JNDI name rather than context name).
Comment 1 Jaroslav Tulach 2002-08-26 16:02:45 UTC
(b) is possible right now, is it not? Client can lookup
java.util.Properties object and work with it. If necessary, the
java.util.Properties can implement javax.naming.Context but I am not
sure why it really should.

Satisfied?
Comment 2 Vitezslav Stejskal 2002-08-26 20:25:32 UTC
No. Client can use properties or persist some more complicated bean with several 
properties. But this limits granularity on which settings can be inherited. When 
setting value can be inherited from parent Context the granularity is given by the 
object stored in the context. In the case of bean or properties, all values stored in 
the bean are eaither inherited or overwritten, which isn't what client wants in many 
cases. Beans should be split to single properties and stored separately, but then 
Context has to be able to persist them efficiently.
Comment 3 Vitezslav Stejskal 2002-10-05 01:50:26 UTC
I think the last decision is to store values of settings of primitive
types in FileObject attributes of Context's folder. I'll go and
enhance implementation in core/naming.
Comment 4 Vitezslav Stejskal 2003-01-08 16:48:25 UTC
Reassigning to core/naming module owner.
Comment 5 David Konecny 2003-02-27 15:29:32 UTC
planned for 4.0
Comment 6 Marian Mirilovic 2003-12-22 13:28:58 UTC
As described in
http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss
the
current work on projects prototype has been stopped.

marking WONTFIX
Comment 7 Marian Mirilovic 2004-04-05 14:29:27 UTC
x
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo