57994 – editorPane.getEditorKitForContentType("text/html") returns an instance of org.netbeans.modules.editor.html.HTMLKit if JEditorPane is used inside a module.

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 57994 - editorPane.getEditorKitForContentType("text/html") returns an instance of org.netbeans.modules.editor.html.HTMLKit if JEditorPane is used inside a module.

Summary: editorPane.getEditorKitForContentType("text/html") returns an instance of org...

Status:	RESOLVED FIXED

Alias:	None

Product:	editor
Classification:	Unclassified
Component:	-- Other -- (show other bugs)
Version:	4.x
Hardware:	All All

Importance:	P2 blocker (vote)
Assignee:	Vitezslav Stejskal

URL:
Keywords:

Duplicates (1):	73177 (view as bug list)
Depends on:	80110
Blocks:	5511 31223 73177
	Show dependency tree

Reported:	2005-04-18 19:01 UTC by _ sandipchitale
Modified:	2007-11-05 13:44 UTC (History)
CC List:	7 users (show)

See Also:
Issue Type:	DEFECT
Exception Reporter:

Attachments
Nb classes using the editor kits registry in JEditorPane. (26.13 KB, text/plain) 2006-07-04 03:31 UTC, Vitezslav Stejskal	Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description _ sandipchitale 2005-04-18 19:01:45 UTC

In the following example:

JEditorPane editorPane = new JEditorPane();
editorPane.getEditorKitForContentType("text/html");
JOptionPane.showMessageDialog(this, new JTextField
(editorPane.getEditorKitForContentType("text/html").getClass().getName()));

inside a module's code always returns:

org.netbeans.modules.editor.html.HTMLKit

instead of the default:

javax.swing.text.html.HTMLEditorKit

The NetBeans code should not make a global change like that. It may be a 
limitation of the swing EditorKit registration mechanism.

Comment 1 Jan Chalupa 2005-04-19 18:31:04 UTC

Yarda? Mila?

Comment 2 Jaroslav Tulach 2005-04-20 15:51:45 UTC

Well, the netbeans code does make such global assumption. If you really want    to use swing editor kit, use JEditorPane.setEditorKit. Am I right Mila?

Comment 3 _ sandipchitale 2005-04-20 17:53:19 UTC

That is precisely the bug about i.e. that the user code should *not* have to 
call JEditorPane.setEditorKit.

Shouldn't NetBeasn code call JEditorPane.setEditorKit whenever it needs the 
special editor kit for content type "text/html"?

Comment 4 Miloslav Metelka 2005-04-20 18:03:54 UTC

Yes, please use JEditorPane.setEditorKit(new HTMLEditorKit()).
For the future promotions we should setup an independent registry for the editor
kits instead of the JEditorPane's one.

Comment 5 Miloslav Metelka 2005-04-20 18:18:34 UTC

Well, it's a question of whether the default should be our kits or swing ones.
If anyone wants to e.g. reuse our java editor with syntax coloring she may do so
just by JEditorPane.setContentType("text/x-java"). On the other hand there is
this clash with the swing html kit. I tend to say that in the future promotions
we should have our extra registry for our kits and leave the implicit one
untouched. However our kits then won't be usable without knowing about that
extra registry. Or we could think about a special non-clashing mime-types for
our kits e.g. for html but that would IMHO be more confusing than useful.

Comment 6 _ sandipchitale 2005-04-20 18:50:31 UTC

I think a programmer would expect a default behaviour for JDK classes unless 
she is made explicitly aware of this modified behavior. By same token, if she 
is aware of these cool NetBeans editor kits and wants to use them, she sure 
can call the JEditorPane.setEditorKit API.

It would not be a big deal if there was no difference in the behavior expected 
by the programmer between the standard JDK kit and this implicit replacement 
kit. However I filed this bug after discovering that there was some difference 
(that I do not recall at the moment) in behavior between HTMLEditorKit and 
org.netbeans.modules.editor.html.HTMLKit.

Secondly, the programmer may be using a binary third party library which 
assumes HTMLEditorKit for content type "text/html" and the programmer may not 
have control over it.

I think I have said all I have to say on this :)

Comment 7 Jesse Glick 2006-06-27 02:51:32 UTC

This problem has been brought up many times on the mailing lists and sometimes
in IZ. I agree with Sandip that the current behavior is unexpected and
confusing. The best solution (IMHO) would be to stop registering EditorKit's in
Swing completely; CloneableEditor (and other clients such as the mini-editors in
the Form module dialogs) would need to look them up using a simple new API, TBD
but probably looking for kits in MIME lookup.

Comment 8 Miloslav Metelka 2006-06-27 14:32:27 UTC

Agreed, although this will be in fact an incompatible change it's desirable IMO.
MimeLookup.getLookup(MimePath.get("text/html")).lookup(EditorKit.class) can be
used to obtain NB kits and is the official API. Not sure whether it's desirable
but please note that the CloneableEditor:1435 will need to call this code
instead of the original             
    kit = JEditorPane.createEditorKitForContentType(mimeType);
and thus openide/text would have to depend on the editor/mimelookup module.

Regarding the implementation there the two options:
 Half-way solution: If there is no kit registered for the particular mime-type
we can continue to return our NB kits for that mime-type from
JEditorPane.getEKFCT().
 Full solution: Never return NB kits for any mime-type from JEditorPane.getEKFCT().

I would personally go with full solution as we could remove the hack that
updates the private static map of the kits in the JEditorPane through the
reflection completely. It's the EditorModule.HackMap and the related code. 
On the other hand the full solution will require to modify all the usages (most
of them are embedded java panes e.g. pre/post init code in form editor or
evaluate expression dialog in debugger etc.) while with the half-way solution
most of the clients would require no changes.

We should make an API review (could be fasttrack IMHO) and communicate the
change on nbdev. We need to update the places where the embedded editor panes
are used.
Reopening the issue.

Comment 9 Jesse Glick 2006-06-27 21:05:15 UTC

I probably agree with the full solution - as you say, it removes the need for
the hackish procedural registration we do today, which is especially troubling
since it accesses sun.** classes.

I am a bit unclear about the partial solution. Are you suggesting removing the
JEditorPane kit registration just for text/html but not for other content types
(most notably text/x-java)?

If so, here's a third possibility: just like the full solution except that
JavaEditorModule.restored would call
JEditorPane.registerEditorKitForContentType. This is a legal API call,
preserving most of the cleanness of the full solution, but would also preserve
backward compatibility for those clients which are trying to display Java source
- probably the overwhelming majority, excepting CloneableEditor. (I can think of
just core/src/org/netbeans/beaninfo/editors/PropertiesCustomEditor.java using
another NB kit.)

By the way, it would hurt nothing (AFAICT) for CloneableEditor to fall back to
JEditorPane's registry in case MIME Lookup produces nothing. This would never be
an issue in NB IDE code but might affect some platform users.

Comment 10 Jaroslav Tulach 2006-06-28 08:54:44 UTC

Sidenote: I sort of like to tell people that the API to get really good 
java/jsp/etc. editor is new JEditorPane().setMimeType("text/x-java")...

Comment: openide/text cannot depend on editor/mimelookup right now as the 
first is in platform cluster and the second in the ide cluster.

Comment 11 Miloslav Metelka 2006-06-28 10:07:36 UTC

Jesse:
 - the partial solution would return the kit registered through the layer
(Editors/<mime-type>/EditorKit.instance) but only in case if there was no
explicit registration by JEP.registerEKFCT().
 - regarding third solution I like it - although it requires explicit
registration in JEP it's fine to do it for a single or few mime-types. The
possible drawback is that a module that would want to override the java editor
kit would have to do it both in Editors/text/x-java/EditorKit.instance and also
in JEP but it's only a detail.

Jarda:
I see. So is there any other suitable solution? Could e.g. the openide/text
instantiate the kit directly from the layer by using
Editors/<mime-type>/EditorKit.instance?

Comment 12 Jesse Glick 2006-06-28 17:27:26 UTC

Or if direct layer lookup does not work well, editor/mimelookup could be moved
into the platform cluster. No non-platform deps and not too big. It has three
easily corrected problems:

1. It defines a layer, which is probably unnecessary. Just contains Editors
folder. Can delete layer (and make code gracefully handle case that this folder
does not exist).

2. It defines an empty ModuleInstall, which should be deleted.

3. It should be autoload but currently is not.

Comment 13 Miloslav Metelka 2006-06-29 15:44:20 UTC

I agree. It seems to me like a more systematic solution. If no one objects we will:
1) Fix the three problems.
2) Make this a fasttrack API review issue.
3) Move editor/mimelookup into platform cluster.
4) Remove EditorModule.HackMap.
5) Register JavaKit by JEditorPane.registerEKFCT().
6) Check the clients that call JEP.setEditorKit() that they still work after the
changes.

Comment 14 Vitezslav Stejskal 2006-06-30 08:25:39 UTC

There should be no ModuleInstall in editor/mimelookup now and I'll have a look
on the rest of the problems as well.

Comment 15 Vitezslav Stejskal 2006-07-04 03:31:20 UTC

Created attachment 31607 [details]
Nb classes using the editor kits registry in JEditorPane.

Comment 16 Vitezslav Stejskal 2006-07-04 04:47:30 UTC

I've attached a list of files from trunk that make a use of the editor kits
registry in JEditorPane - basically grep for set{get}EditorKitForContentType,
registerEditorKitForContentType, createEditorKitForContentType,
getEditorKitClassNameForContentType and set{get}ContentType with some manual
intervention to filter out rubbish. It seems to me that:

1. there is quite a lot of modules that rely on JEP.setContentType to give them
Nb editor kits
2. modules providing editor kits do not usually register them using
JEP.registerEKForCT and rely on the editor module to pick up the kits from lookup
3. anybody using JEP for 'text/html' expects to get Nb editor kit and if they
want the default one from JDK they call JEP.setEKForCT(new HTMLEditorKit())

Please correct me if I am wrong, but when going ahead with the full solution I
can see the following consequences.

A. All modules that are using JEP.createEKForCT or JEP.setContentType will have
to be converted to use the MimeLookup registry such as:

  EditorKit kit = (EditorKit) MimeLookup.getLookup(MimePath.get("text/html"))
                                .lookup(EditorKit.class);
  JEP.setEditorKit(kit);

We should mirror default JDK editor kits in MimeLookup to make the MimeLookup
registry complete.

We could possibly provide a convenience method BaseKit.getKit(String mimePath),
which would encapsulate somewhat awkward call to MimeLookup.

B. Modules providing editor kits will always have to register their kit in
'Editors/<mime-type>' to make it available in MimeLookup. Optionally they can
call JEP.registerEKForCT to make the kit available directly from JEP. This
however should only be used if there is no default EK registered in JEP for a
given mime type.

Now, is the full solution still the way to go? Or shall we go with the partial
solution as described by Mila and advertise the new concept in the
docs/tutorials/etc and slowly migrate modules to use it? Or am I completely wrong?

Comment 17 Jesse Glick 2006-07-12 01:05:45 UTC

Hmm, seems there are bigger compatibility implications than I thought. That's
quite a lot of code expecting to use JEP's registry. Maybe it's too late to do
this without risking incompatibilities for third-party modules.

Comment 18 Vitezslav Stejskal 2006-07-12 06:28:44 UTC

Just for the record, I found this TCA - issue #52657.

Comment 19 Vitezslav Stejskal 2006-08-03 09:48:58 UTC

This has been fixed. Here is the list of things I've done:

1. editor/mimelookup and editor/mimelookup/impl are in the platform cluster
2. CloneableEditorSupport.getEditorKit(String) has been added and uses
mimelookup to find EditorKits
3. the HackMap in the editor module is still around and therefore JEP's registry
keeps returning Netbeans EditorKits from mimelookup (as before) except for the
following mime types: text/html, text/rtf and application/rtf; kits for these
mime types are *always* taken from JDK
4. (hopefully) all places affected by the change in the JEP's behavior regarding
text/html kits have been updated to use CloneableEditorSupport.getEditorKit

Here is the CVS log:

Checking in diff/nbproject/project.xml;
/cvs/diff/nbproject/project.xml,v  <--  project.xml
new revision: 1.15; previous revision: 1.14
done
Checking in diff/src/org/netbeans/modules/diff/EncodedReaderFactory.java;
/cvs/diff/src/org/netbeans/modules/diff/EncodedReaderFactory.java,v  <-- 
EncodedReaderFactory.java
new revision: 1.12; previous revision: 1.11
done
Checking in diff/src/org/netbeans/modules/diff/builtin/visualizer/DiffPanel.java;
/cvs/diff/src/org/netbeans/modules/diff/builtin/visualizer/DiffPanel.java,v  <--
 DiffPanel.java
new revision: 1.32; previous revision: 1.31
done
Checking in diff/src/org/netbeans/modules/diff/builtin/visualizer/DiffViewImpl.java;
/cvs/diff/src/org/netbeans/modules/diff/builtin/visualizer/DiffViewImpl.java,v 
<--  DiffViewImpl.java
new revision: 1.24; previous revision: 1.23
done
Checking in diff/src/org/netbeans/modules/merge/builtin/visualizer/MergePanel.java;
/cvs/diff/src/org/netbeans/modules/merge/builtin/visualizer/MergePanel.java,v 
<--  MergePanel.java
new revision: 1.40; previous revision: 1.39
done
Checking in editor/codetemplates/nbproject/project.xml;
/cvs/editor/codetemplates/nbproject/project.xml,v  <--  project.xml
new revision: 1.4; previous revision: 1.3
done
Checking in
editor/codetemplates/src/org/netbeans/lib/editor/codetemplates/CodeTemplateManagerOperation.java;
/cvs/editor/codetemplates/src/org/netbeans/lib/editor/codetemplates/CodeTemplateManagerOperation.java,v
 <--  CodeTemplateManagerOperation.java
new revision: 1.7; previous revision: 1.6
done
Checking in editor/nbproject/project.properties;
/cvs/editor/nbproject/project.properties,v  <--  project.properties
new revision: 1.23; previous revision: 1.22
done
Checking in editor/nbproject/project.xml;
/cvs/editor/nbproject/project.xml,v  <--  project.xml
new revision: 1.25; previous revision: 1.24
done
Checking in editor/options/nbproject/project.xml;
/cvs/editor/options/nbproject/project.xml,v  <--  project.xml
new revision: 1.15; previous revision: 1.14
done
Checking in
editor/options/src/org/netbeans/modules/options/codetemplates/CodeTemplatesPanel.java;
/cvs/editor/options/src/org/netbeans/modules/options/codetemplates/CodeTemplatesPanel.java,v
 <--  CodeTemplatesPanel.java
new revision: 1.24; previous revision: 1.23
done
Checking in editor/options/src/org/netbeans/modules/options/colors/ColorModel.java;
/cvs/editor/options/src/org/netbeans/modules/options/colors/ColorModel.java,v 
<--  ColorModel.java
new revision: 1.27; previous revision: 1.26
done
Checking in editor/src/org/netbeans/modules/editor/EditorModule.java;
/cvs/editor/src/org/netbeans/modules/editor/EditorModule.java,v  <-- 
EditorModule.java
new revision: 1.121; previous revision: 1.120
done
Checking in editor/test/build-qa-functional.xml;
/cvs/editor/test/build-qa-functional.xml,v  <--  build-qa-functional.xml
new revision: 1.24; previous revision: 1.23
done
Checking in editor/test/cfg-qa-functional.xml;
/cvs/editor/test/cfg-qa-functional.xml,v  <--  cfg-qa-functional.xml
new revision: 1.45; previous revision: 1.44
done
RCS file: /cvs/editor/test/qa-functional/src/general/EditorKitsRegistryTest.java,v
done
Checking in editor/test/qa-functional/src/general/EditorKitsRegistryTest.java;
/cvs/editor/test/qa-functional/src/general/EditorKitsRegistryTest.java,v  <-- 
EditorKitsRegistryTest.java
initial revision: 1.1
done
Checking in editor/test/qa-functional/src/general/GeneralTestSuite.java;
/cvs/editor/test/qa-functional/src/general/GeneralTestSuite.java,v  <-- 
GeneralTestSuite.java
new revision: 1.4; previous revision: 1.3
done
Checking in
editor/test/qa-functional/src/org/netbeans/test/editor/app/core/EventLoggingEditorPane.java;
/cvs/editor/test/qa-functional/src/org/netbeans/test/editor/app/core/EventLoggingEditorPane.java,v
 <--  EventLoggingEditorPane.java
new revision: 1.6; previous revision: 1.5
done
Checking in
editor/test/qa-functional/src/org/netbeans/test/editor/indentation/programmatic/IndentCore.java;
/cvs/editor/test/qa-functional/src/org/netbeans/test/editor/indentation/programmatic/IndentCore.java,v
 <--  IndentCore.java
new revision: 1.4; previous revision: 1.3
done
Checking in ide/golden/deps.txt;
/cvs/ide/golden/deps.txt,v  <--  deps.txt
new revision: 1.298; previous revision: 1.297
done
Checking in
j2ee/blueprints/src/org/netbeans/modules/j2ee/blueprints/ui/HtmlBrowserWithScrollPosition.java;
/cvs/j2ee/blueprints/src/org/netbeans/modules/j2ee/blueprints/ui/HtmlBrowserWithScrollPosition.java,v
 <--  HtmlBrowserWithScrollPosition.java
new revision: 1.9; previous revision: 1.8
done
Checking in java/nbproject/project.xml;
/cvs/java/nbproject/project.xml,v  <--  project.xml
new revision: 1.22; previous revision: 1.21
done
Checking in java/src/org/netbeans/modules/java/IndentFileEntry.java;
/cvs/java/src/org/netbeans/modules/java/IndentFileEntry.java,v  <-- 
IndentFileEntry.java
new revision: 1.16; previous revision: 1.15
done
Checking in javadoc/nbproject/project.xml;
/cvs/javadoc/nbproject/project.xml,v  <--  project.xml
new revision: 1.12; previous revision: 1.11
done
Checking in
javadoc/src/org/netbeans/modules/javadoc/comments/JavaDocEditorPanel.form;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/JavaDocEditorPanel.form,v
 <--  JavaDocEditorPanel.form
new revision: 1.23; previous revision: 1.22
done
Checking in
javadoc/src/org/netbeans/modules/javadoc/comments/JavaDocEditorPanel.java;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/JavaDocEditorPanel.java,v
 <--  JavaDocEditorPanel.java
new revision: 1.60; previous revision: 1.59
done
Checking in javadoc/src/org/netbeans/modules/javadoc/comments/ParamTagPanel.form;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/ParamTagPanel.form,v  <--
 ParamTagPanel.form
new revision: 1.11; previous revision: 1.10
done
Checking in javadoc/src/org/netbeans/modules/javadoc/comments/ParamTagPanel.java;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/ParamTagPanel.java,v  <--
 ParamTagPanel.java
new revision: 1.27; previous revision: 1.26
done
Checking in javadoc/src/org/netbeans/modules/javadoc/comments/SeeTagPanel.form;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/SeeTagPanel.form,v  <-- 
SeeTagPanel.form
new revision: 1.10; previous revision: 1.9
done
Checking in javadoc/src/org/netbeans/modules/javadoc/comments/SeeTagPanel.java;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/SeeTagPanel.java,v  <-- 
SeeTagPanel.java
new revision: 1.24; previous revision: 1.23
done
Checking in
javadoc/src/org/netbeans/modules/javadoc/comments/SerialFieldTagPanel.form;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/SerialFieldTagPanel.form,v
 <--  SerialFieldTagPanel.form
new revision: 1.11; previous revision: 1.10
done
Checking in
javadoc/src/org/netbeans/modules/javadoc/comments/SerialFieldTagPanel.java;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/SerialFieldTagPanel.java,v
 <--  SerialFieldTagPanel.java
new revision: 1.26; previous revision: 1.25
done
Checking in javadoc/src/org/netbeans/modules/javadoc/comments/StandardTagPanel.form;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/StandardTagPanel.form,v 
<--  StandardTagPanel.form
new revision: 1.9; previous revision: 1.8
done
Checking in javadoc/src/org/netbeans/modules/javadoc/comments/StandardTagPanel.java;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/StandardTagPanel.java,v 
<--  StandardTagPanel.java
new revision: 1.25; previous revision: 1.24
done
Checking in javadoc/src/org/netbeans/modules/javadoc/comments/ThrowsTagPanel.form;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/ThrowsTagPanel.form,v 
<--  ThrowsTagPanel.form
new revision: 1.10; previous revision: 1.9
done
Checking in javadoc/src/org/netbeans/modules/javadoc/comments/ThrowsTagPanel.java;
/cvs/javadoc/src/org/netbeans/modules/javadoc/comments/ThrowsTagPanel.java,v 
<--  ThrowsTagPanel.java
new revision: 1.27; previous revision: 1.26
done
Checking in openide/awt/src/org/openide/awt/SwingBrowserImpl.java;
/cvs/openide/awt/src/org/openide/awt/SwingBrowserImpl.java,v  <-- 
SwingBrowserImpl.java
new revision: 1.4; previous revision: 1.3
done
Checking in openide/text/src/org/openide/text/CloneableEditorSupport.java;
/cvs/openide/text/src/org/openide/text/CloneableEditorSupport.java,v  <-- 
CloneableEditorSupport.java
new revision: 1.24; previous revision: 1.23
done
Checking in vcscore/nbproject/project.xml;
/cvs/vcscore/nbproject/project.xml,v  <--  project.xml
new revision: 1.18; previous revision: 1.17
done
Checking in
vcscore/src/org/netbeans/modules/vcscore/ui/views/types/UpdateStdOutPanel.java;
/cvs/vcscore/src/org/netbeans/modules/vcscore/ui/views/types/UpdateStdOutPanel.java,v
 <--  UpdateStdOutPanel.java
new revision: 1.4; previous revision: 1.3
done
Checking in web/jspsyntax/manifest.mf;
/cvs/web/jspsyntax/manifest.mf,v  <--  manifest.mf
new revision: 1.30; previous revision: 1.29
done
Checking in web/jspsyntax/nbproject/project.properties;
/cvs/web/jspsyntax/nbproject/project.properties,v  <--  project.properties
new revision: 1.21; previous revision: 1.20
done
Checking in web/jspsyntax/nbproject/project.xml;
/cvs/web/jspsyntax/nbproject/project.xml,v  <--  project.xml
new revision: 1.18; previous revision: 1.17
done
Checking in web/jspsyntax/src/org/netbeans/modules/web/core/syntax/JSPKit.java;
/cvs/web/jspsyntax/src/org/netbeans/modules/web/core/syntax/JSPKit.java,v  <-- 
JSPKit.java
new revision: 1.29; previous revision: 1.28
done
Checking in
web/jspsyntax/src/org/netbeans/modules/web/core/syntax/JspSyntaxSupport.java;
/cvs/web/jspsyntax/src/org/netbeans/modules/web/core/syntax/JspSyntaxSupport.java,v
 <--  JspSyntaxSupport.java
new revision: 1.83; previous revision: 1.82
done
Checking in
web/jspsyntax/src/org/netbeans/modules/web/core/syntax/completion/JspCompletionSupport.java;
/cvs/web/jspsyntax/src/org/netbeans/modules/web/core/syntax/completion/JspCompletionSupport.java,v
 <--  JspCompletionSupport.java
new revision: 1.5; previous revision: 1.4
done
Checking in
websvc/registry/extsrc/org/netbeans/modules/websvc/registry/ui/AddWebServiceDlg.java;
/cvs/websvc/registry/extsrc/org/netbeans/modules/websvc/registry/ui/AddWebServiceDlg.java,v
 <--  AddWebServiceDlg.java
new revision: 1.10; previous revision: 1.9
done
Checking in xtest/instance/master-config.xml;
/cvs/xtest/instance/master-config.xml,v  <--  master-config.xml
new revision: 1.195; previous revision: 1.194
done

Comment 20 Jesse Glick 2007-11-03 18:56:24 UTC

*** Issue 73177 has been marked as a duplicate of this issue. ***