Bug 36297

Here is status update on this task (issue 35050). I've rewritten
core/registry to use Convertor API couple of weeks ago, but did not
finish it completely and moved doing something else. Yesterday I
returned to it and I'm almost ready to commit it to CVS. All what
remains to do is to add couple of tests. The implementation is fully
based on Convertors and for .settings and .instance formats it has
hardcoded support which does not use Datasystems. It also listens on
installed modules and enables/disables .settings bindings accordingly.
(this is not cover by tests yet and I would like to finish it today).

The problem with integration to trunk are projects. They are already
using current Registry and in order to not break their build for
couple of days I have to put this on some branch and ask them to
migrate to it as soon as possible. The problems they have to solve is:
* rewrite all existing core/settings convertors to new Convertor API
(should be trivial)
* rethink all convertors which depends on Lookup parameter (not
supported in new Convertor API)
* no autosave of objects

I plan to create branch on Monday. I'm WFH today.

Reading this issue I realized one thing: if there is ever (backward
compatibility) problem that Registry and Datasystems creates two
difference instances from one .settings file or if there are some
problems with subclasses of SharedClassObject then we could let the
Datasystems to process its old formats (.settings and .instance
files), but ask/force module writers to stop using them immediatelly
and move to new formats.

This is open option. At the moment my impl does not need DS, because
it is quite simple to manage these formats.

OK, this is all fine, but actually my implementation should be
practically 100% backward-compatible - I don't think it would affect
the projects branch at all. It is just a refinement to the current
core/registry and still uses old DS in the background.

It supports the Convertors API for *.xml - not *.settings; actually I
am not sure why we need the special filename suffix at all. All it
does is check for XML files which do not *otherwise* have an
InstanceCookie from old DS, and which have a namespace and which are
registered. So any existing settings file is unaffected. Only affected
are XML files which previously would have been ignored - now they
appear in the context.

Does not currently attempt anything fancy like listening to changes in
modules.

Anyway, the advantage of this patch is that it is possible to try out,
and use, the new Convertors API on things you are interested in,
without any effect on other code. So it could be a useful intermediate
step in the migration. I am using it successfully to integrate Conv
API into the minicomposer demo - playing with usages of Reg/Conv for
settings storage.

Will attach patch, you can evaluate whether this would be reasonable
to put into the trunk in the short term, while a slicker DS-less
solution is being developed.

Created attachment 11724 [details]
Simple trunk patch - working fine for me

Observed bugs in my impl so far:

1. After reloading a module, convertors not rerun, so you still get
the old instance.

I reviewed it and I like it. Thanx! Go ahead and commit it to trunk.

I agree that this way the migration for projects is much easier and
once they kill all their old core/settings convertors we can switch to
my DS-free reimplementation. Thanx for idea and help.

Re: module reloading bug - I think it is acceptable for this impl. It
is temporary.

Davide, is there any description of how to migrate old convertors to
new infrastructure? Could you please file a bug for projects that we
should rewrite our convertors and put in there the link to that
transition guide. Thanks.

I will file issue. The Convertor API can be found at
<http://www.netbeans.org/download/dev/javadoc/ConvertorAPI/index.html>.
It has couple of detailed Javadoc overviews. The unit tests contain
three module jars with illustrative implementation of different
convertor types. I can write up paragraph or two about migration, but
from the docs above it should be really simple.

OK, javadoc and overview pages seem good. I think we will be able to
follow instructions and rewrite our convertors. Thx.

Implemented in trunk:

committed   * Up-To-Date  1.12        core/registry/build.xml
committed   * Up-To-Date  1.7         core/registry/manifest.mf
committed   * Up-To-Date  1.2         core/registry/api/apichanges.xml
committed   * Up-To-Date  1.2        
core/registry/src/org/netbeans/core/registry/olddsimpl/DSUtils.java
committed   * Up-To-Date  1.7        
core/registry/src/org/netbeans/core/registry/olddsimpl/ObjectBindings.java
committed   * Up-To-Date  1.4         core/registry/test/build.xml
added       * Up-To-Date  1.1        
core/registry/test/unit/src/META-INF/MANIFEST.MF
added       * Up-To-Date  1.1        
core/registry/test/unit/src/org/netbeans/core/registry/ConvertedObjectTest.java
added       * Up-To-Date  1.1        
core/registry/test/unit/src/org/netbeans/core/registry/convertors/TestBean.java
added       * Up-To-Date  1.1        
core/registry/test/unit/src/org/netbeans/core/registry/convertors/TestBeanConvertor.java
added       * Up-To-Date  1.1        
core/registry/test/unit/src/org/netbeans/core/registry/data/object-layer.xml
committed   * Up-To-Date  1.361       nbbuild/build.xml
committed   * Up-To-Date  1.5         openide/registry/test/build.xml

Also in prj40_prototype:

committed   * Up-To-Date  1.1.2.83    build.properties
committed   * Up-To-Date  1.185.2.85  build.xml