Define "project".  But more generally, I'd say that'd be a function of the  
rest of your code.  I presume that normally, you'd just rely on the  
destruction of the frame and contained objects associated with the  
"project" to release the menu.

In this case, you'd also want to remove your menu instance from the  
collection the factory is managing, right?

Depending on how you're dealing with the destruction of the project, I  
suppose there are a variety of ways you could react to this event.  But  
one obvious answer seems to be that you could add a WindowListener to the  
frame so that you are called when it's closing or closed.  At that point,  
you'd destroy whatever resources are associated with the project,  
including the factory's reference to the menu (the menu(s)  
itself(themselves) used by the frame would be destroyed with the  
destruction of the frame, presumably...and I use the term "destroy"  
loosely since I'm not really sure at what point things get disposed versus  
just not being referenced any longer...I assume that disposing the frame  
disposes all of the contents, but like I said, I'm new to Java :) ).

I assume that in this case by "InsertMenu" you mean the actual Java menu,  
and not the factory itself (and of course that assumes we're talking about  
going with a factory implementation rather than a singleton, as a  
work-around to the "no multiple parents" issue).

I see.  Again, I doubt it matters but...do you really need this singleton  
to be thread-safe?  I like lazy instantiation, but I think it's a bit  
clearer to write the code explicitly rather than relying on the specific  
behavior of the language.  If you don't need to synchronize access to the  
singleton, the simple "if null then instantiate" approach won't clutter up  
the code very much at all.  Maybe that's just me though.  :)

Pete

[Snip discussion about MenuItems only being in one menu at a time]

Well, the standard Swing approach is to use some type of data model,
which is shared among different realizations.  You then build a factory
that keeps a single data model and arranges for all of the components
that can change it to each use the same one.

Now, for menu items this is a bit trickier, since they don't normally
have an explicit model associated with them.  What is it that needs to
be updated everywhere?  What does InsertMenu do anyway?

Perhaps the answer is to build your own subclass of MenuItem that does
have a model which can be shared among instances, and that will take
care of doing the appropriate updating.

Well, normally you don't need to worry about such destruction.  I
suppose if you go the factory route, you don't want to keep old items
around that are no longer needed (since that would inhibit garbage
collection).

If you went to a shared model architecture, that should largely take
care of itself, unless you had a reverse link between the model and its
realizations.

I suppose in either case, you could try making use of one of the weak
reference methods to keep one direction of reference, so that the links
wouldn't inhibit garbage collection.

On the other hand, unless there are really going to be a really big
number of these items, it might not be worth the trouble to worry
about.

Alright.  My coworker and I came up with a good solution that solves
the issue and gives us context sensitive menus.

Basically, we made InsertMenu *not* a singleton and, instead,
overwrote JMenuItem so that, when it is enabled or disabled, it is
also set visible/invisible, respectively (overwrote "setEnabled" and
"setVisible" so they stay consistent).  That way, when the Action (we
have an ActionFactory) is enabled or disable, it will carry over to
our JMenuItem.

It works beautifully and is much better than having a Singleton of the
InsertMenu.

Thanks for the help.  :-)