EmbeddedFrame's dont get added to the toolkit.peerMap

Since EmbeddedFrame's are not entered into the SunToolkit.peerMap the targetToPeer() method returns null.

This results in any attempt to embed a Component into an EmbeddedFrame to fail
as the peer's native code "create" method (for heavyweight peers) gets passed
a NULL parent pointer.

Summary of Issues/Status of Bug no 4070002
===========================================

A SunSoft ISV, ArborText, is building a Java application on Win32 and
Solaris. Eduardo Gutentag from Sun has been working with them.

ArborText wants to place JavaBeans into windows created via native (i.e.,
C) code. On Win32, this is accomplished via the JavaBeans ActiveX Bridge.
This is a mechanism distributed by JavaSoft.

There is no comparable mechanism for Solaris. At some point, someone at
ArborText spoke with folks at JavaSoft, and was told to "reverse engineer"
the Win32 ActiveX Bridge and implement similar functionality on Solaris.
In particular it was suggested that ArborText use Java classes (e.g.,
EmbeddedFrame) that are not part of the public API set.

ArborText tried to follow this advice and found that it was not possible to
embed JavaBeans in C/Motif UI windows. The latest problem is reported in
Bug report 4070002. The suggested fix in this bug report [declare
EmbeddedFrame protected], is of no value. The fix has already been made
in all versions of the JDK, and does not address the problem that ArborText
saw.

The JTG-libs group tried to implement a different, more specific fix
[adding MEmbeddedFrame to the PeerMap]. While the immediate symptom was
corrected, that fix creates subsequent problems.

As a result of this effort, it's been realized that the basic problem is
that there is no Solaris project corresponding to development of the
ActiveX Bridge. That is, the real answer to ArborText's problem is to
develop a reliable and well-understood mechanism for embedding JavaBeans in
C/Motif UI windows. There are many technical challenges to deal with in
such a project. In addition to basic display of components, there are
design issues relating to event handling, geometry management, etc. This
would be a sizeable development project for engineers already conversant
with JavaBeans and the problems of embedding them in native windows.

Such a true fix is beyond the capabilities of the JTG-libs team, and no
simpler solution seems workable.


Here is the info that clarifies customer's situation.
(Note: my questions to the customer start with > and
 Answers from Jeff Barr, contractor working for ArborText
 follow after my questions)

> I did some more investigation of your test case
> and some part of JDK source code.
>
> It seems like you are trying to embed visual java bean into
> C/Motif program.

Correct!

> EmbeddedFrame is not part of public apis, were you advised by
> someone from Sun to use EmbeddedFrame ?

I was advised (by Sun) that I should reverse-engineer the ActiveX
Bridge to learn how to host a bean within a legacy application.

>> Did you submit this bug report ? Or did you contact someone
>> from Sun to report this bug ?

I had a conference call with Larry Cable. As a result of the
call, Larry submitted the bug.


=================================================================

Here is the original trail of emails that was sent to me.

> ------------- Begin Forwarded Message -------------
>
> Date: Thu, 21 Aug 1997 07:53:44 -0700 (PDT)
> From: Eduardo Gutentag <eduardo@rug>
> Subject: May I call your attention to #4070002
> To: craig.rolandelli@Eng, alok.rishi@Eng, rick.levenson@Eng
> cc: eduardo@rug
>
> Hi,
>
> I hope one of you can help me to either have SunSoft work on this or pass/push
> it through to JavaSoft.
>
> We have a customer (ArborText Inc.) that is also the supplier of SunSoft's
> SGML editing tool. They are trying to incorporate JavaBeans in their product.
> They have now stumbled on bug 4070002 (java/classes_awt); this was filed
> August 6, and as of today it had neither been accepted nor evaluated. They
> are of course working against a scheduled release of the product. It would
> be highly ironic if the Solaris version of their product does not incorporate
> Java, but their Wintel version does...
>
> Below is a slightly edited (shortened) version of their email to me.
>
> Any help (even pointers as to who would be more appropriate as a target for
> this correspondence) would be greatly appreciated.
>
> Eduardo
> >
> >----- Begin Included Message -----<
>
> >
> >The problem is a bug in the Java VM which prevents us from
> >embedding a Java Bean directly in a frame - something that
> >is supposed to work. No problem putting a bean in its own
> >frame.
> >
> >I've attached a description of the problem/solution - it's
> >pretty simple and it's something that they are fixing in the
> >next release. That won't do us any good for 7.0, so a strong
> >request from Sun to Javasoft appears to be the only option
> >to get this fixed - or switch to the MS Java VM, go out with
> >Java only for Windows, and add Solaris support when the MS VM
> >is out for Solaris. I would prefer not to do this, although
> >right now it is my only option.
> >
> >[See Attached]
> >
> >Mike
> >
> >================================================================
> >
> > NOTE: HERE IS A FIX THAT WAS SUGGESTED BY SOMEONE NAMED JEFF
           FROM JAVASOFT OR SUNSOFT, I COULD NOT TRACE THIS PERSON
SINCE I HAD ONLY FIRST NAME.
FIX NO.1 IS PRESENT IN JDK1.1.1, JDK1.1.3, JDK1.1.4
so this does not seem to be the correct fix.

> >Mike,
> >
> >Here is the information that you requested:
> >
> >The problem is in file "src/solaris/sun/sun/awt/motif/MToolkit.java".
> >The peerMap data structure is declared as private and final. This
> >makes itinaccessible to the outside world. To fix this one of the
> >following changes should be made:
> >
> >1. The declaration should be changed to protected, allowing access
> > from a subclass, or
> >
> >2. A new entry point should be added to the class to allow an
> > external piece of code to make entries in the peerMap.
> >
> >I prefer the latter solution.
> >
> >If anyone needs more information they can call me or Larry
> >Cable. The problem was filed as Sun bug #4070002.
> >
> >Later,
> >
> >Jeff;

> >----- End Included Message -----<
>
> ------------- End Forwarded Message -------------
>
> ----- End Included Message -----
>
> Second message follows:
>
> ----- Begin Included Message -----
>
> >From craigr@squaw-valley Thu Aug 21 16:47 PDT 1997
> Date: Thu, 21 Aug 1997 16:46:17 -0700 (PDT)
> From: Craig Rolandelli <craigr@squaw-valley>
> Subject: Re: May I call your attention to #4070002
> To: sfm@squaw-valley, dan@squaw-valley
>
> ------------- Begin Forwarded Message -------------
>
> Date: Thu, 21 Aug 1997 16:31:09 -0700
> From: Alok Rishi <alokr@Eng>
> To: Eduardo Gutentag <eduardo@rug>
> Cc: craig.rolandelli@Eng, alok.rishi@Eng, rick.levenson@Eng
> Subject: Re: May I call your attention to #4070002
>
> I'll try to mobilize AWT resources here and look into this.
>
> In case a fix looks doable, whats a timeframe/release when they can
> accept a JDK fix? I assume the next JDK after sparkler (1.1.4)? Do
> they use the JDK from JavaSoft or SunSoft?
>
> Alok
  


alka.deshpande@East 1997-09-11